The Toolshed

A place for visioning, tinkering, and building around the topics of education reform, technology, and female entrepreneurship.

Month: January, 2014

Standing Meetings: A Surefire Way to Kill Momentum.

I recently told a friend: “There’s no way to kill momentum like a standing meeting.”  Despite the hyperbole, I think there’s something to this.  When I assumed director-level status at my previous employer, the first thing I did was do away with standing meetings within my department (and, later, the entire organization).  Standing meetings are often put in place with the best of intentions: senior leadership want regular communication, an open forum for conversation, and either intra- or inter-departmental exchange.  Some might even talk about the fact that these meetings “establish a regular drumbeat” for progress, or that they hold all team members accountable for week-on-week accomplishment.

But in reality, they rarely accomplish much.  In most standing meetings in which I’ve participated, we go around the room to share updates with one another, which in turn means that staff feel compelled to exaggerate their progress and/or talk at length about projects that are neither interesting or relevant to the majority of the rest of the meeting.  Worse, they typically stymie employee productivity for the day — if I open my calendar at 9 AM and see the standing meeting at 9:30 AM, I will probably defer throwing myself into a project until after the meeting.  (Yes, this touches on the broader issue of maker vs. manager time, but I think that standing meetings have a propensity to truly deter the potential for productivity in a given day.)  They also kill energy.  I guarantee that the majority of your staff and your co-workers dread their standing meetings and mentally prepare for an hour of day-dreaming. (That’s another frustrating facet of the standing meeting: they almost always drag on too long.)

There are, of course, circumstances in which regular meet-ups are necessary — typically around specific projects with specific completion dates.  But I would take great pains to refashion and reframe these regular convenings.  In my former position, I called project-specific weekly meetings either “scrums” or “stand-ups.”  The emphasis was on brevity and informality — “Quick, let’s put our heads together to make sure we can work through this specific issue” or “OK, shoot: tell me where we are with x.”  And I  would often actually stand up during them — you move through necessary topics much more quickly and you feel more energized.  I would also liberally cancel them if there was nothing to report or review.  I’m currently working on a project with our developers, and they share a similar ethos: we have no standing agenda.  If we have nothing to cover at the outset of the meeting, we dismiss immediately.

Am I being overly Draconian on the topic of standing meetings?  Probably.  But in a time where many companies are looking for ways to become leaner, more agile, more innovative, I would suggest trimming the fat wherever possible within your employees’ workdays.  What are the recurring events, processes, and deliverables that you assign your employees that yield minimum benefit?  I would boldly venture to guess that standing meetings almost universally fall into this category.  I would also reflect on the desired outcomes of these meetings — what do they accomplish?  Is the goal to get everyone on the same page?  Encourage progress?  Call out strong performance?  Etc.?  There are probably more creative and engaging ways to get the same results without the pain of an hour-long all-hands.

Am I off-target here?

 

 

Advertisements

The Technical Divide.

I read three interesting articles on women in technology this week: one by a male programmer angered by the fact that he had enjoyed certain privileges by “looking the part” (i.e., fitting the gender and ethnic norms as to what a “programmer” looks like) while friends of different ethnicities and the opposite gender had been micro-bullied out of the industry; another by a female programmer frustrated by  her position outside of the “technically entitled” caste because of her gender; and a final one about steps companies can take to attract and retain women in their technology departments.

I always cringe when I read these articles.  I find myself sucking in or holding my breath or contorting my body in a strange way.  I think it’s because many of these articles teeter dangerously on the edge of circular reasoning.  That is, they pose an argument that is useless because their conclusion is one of their premises: women should be in technology because women should be in technology.   And there’s nothing like circular logic disguised as a truism to hook unwilling listeners.  I don’t denigrate the impulse, the frustration, the genuine anger, especially in the voice of Tess Rinearson above.  In fact, I share it.  And I’m glad that there are women and men upset by the obvious imbalance and the “micro-aggressions” (I’m borderline on that concept) they experience in the workplace and beyond.  I’m thrilled that this is a conversation.  I’m ecstatic that women are leaning in.   (I should mention that I am a huge, huge, huge fan of Sheryl Sandberg’s — I listen to her TED talk before I need to deliver a big presentation or attend an important meeting.  Her success and her thoughtfulness about it — pure adrenaline.)

But then I read a statement like this: “This problem can be fixed, but we need to start by acknowledging that the fault is with the employer rather than with women.”  [Insert me wringing my hands.]  There must be a more elegant, meritocratic, thoughtful approach to this issue than villainizing corporate America.  At a minimum, let’s acknowledge that employers are only a part of the issue.  What do we learn from our families, communities, religions, political environments as we’re growing up?  Who are our role models?  What do our educators tell us?  What do our peers tell us?  What do our magazines tell us?  What do our books tell us?  What do our toys tell us?  I resent the idea that women can’t “make it” because a group of smarmy men are sitting in a back room, burning the resumes of female applicants — which, while I exaggerate the representation, is frankly not that far off from what you’ll read.  I guess that I feel uncomfortable — angry? — when articles make me feel as though I’m a victim.  I don’t want that label, thankyouverymuch.  I want to be a competitor.

In my opinion, the most powerful lever for change is in women in the aggregate — that is, women who are willing to band together and help other girls and women up the ladder.  (Heads up: I’m importing Sheryl Sandberg’s credo here, nearly wholesale.  If you’ve not yet Lean In yet, get thee to Amazon.)  In order to change the equation, we need to have female pioneers who make it to the top and both proactively help others into the network and, more passively, serve as a role model for future generations.  We need forums for women to gather, set a precedent, and make a statement en masse.  We need spaces and programs geared specifically towards teaching girls and women to code.  This is why I’ve co-founded a chapter of the EdTechWomen  community up here in Chicago.  This is why I have been hauling ass the last few years, chasing the C-level — at least, in part.  Part of it was just me wanting to do me.

 

Thoughts on App Success Measurement.

When I was getting my feet wet with app development,  I spent some time studying up on metrics for app success.  I found that a lot of the metrics conventionally applied — conversion rates (ARPU or average revenue per user), usage (DAU – daily active user / MAU – monthly active user), session length — either did not apply or would not really tell us anything about whether our app was successful in helping our teens build their financial capability.  For example, while we do expect a lot of touchpoints between the student and the app in order to track their progress within the app, length of session is not necessarily a critical metric for success.  I’m more interested in knowing whether a kid sets a goal and meets it.  Or whether a kid successfully creates a LinkedIn account and adds five contacts.  Both of these examples are among the challenges in our nine-week challenge curriculum for the pilot this spring — and neither of them requires much time in-app.  (N.B.: As a reminder, the Moneythink app is an interactive social platform designed to engage youth around financial challenges that build financial awareness, skills, and habits.  The challenges are issued and facilitated and, in some cases, verified by Moneythink mentors, though engagement is largely driven by peer-to-peer interactions in the app.  Youth earn points for completing challenges that they can ultimately “cash in” for real-world rewards.)

metrics2

 

{A lot to digest…}

I was fortunate enough to speak with the incredibly sharp Mark Bruinooge, CEO of Tykoon, who shed some important light on success measurement.  Tykoon is a mobile experience that “empowers kids and their families to develop stronger financial habits and values through real-life learning experiences.”  Kids are able to tick off chores that they complete in order to earn IOUs from their parents for money that they can ultimately redeem to purchase items that they want.  The idea is that the app serves as a mobile intervention of sorts — kids use the app to record their purchasing goals  and then can track their progress towards those goals, ideally spurring multiple conversations about saving, spending, goal-setting, and beyond with their parents.  Mark pointed out that the success of Tykoon centers around whether parents are able to have those offline conversations with their kids — something not immediately measurable by the technology.  It occurs to me that Moneythink shares a similar quandary — believing as we do in the efficacy of a blended learning model, where kids “do things” using technology and then their mentors review those “doings” in order to create a teachable moment in class — much of the success relies on the effective communication of feedback in the classroom.  And how do we quantify that?

phone-child-tasks

 

{Tykoon‘s child-facing mobile app design.}

At the same time, many of the challenges that students will complete have intrinsic behavior measurement opportunities — for example, in one challenge, as I referenced above, students set a minigoal for themselves.  They set their goal and then snap a photo when they’ve achieved it.  These can be as small as “I want to save $5 this week.  I’ll do it by avoiding Starbucks tomorrow.”  The end goal is not only more money in the student’s pocket, but an inclination toward more mindful spending and evidence of self-discipline.  (One of the most startling aspects of the prototype was seeing how thoughtlessly our teens use their spending money — most of them report that they don’t know where their money goes, that it seems to disappear, etc.  When we mined the SnapTrack news feed we set up in our prototype, we saw exactly where it went: the vending machine, fast food restaurants, and the occasional discount clothing store.)

At any rate, I’m landing in a place where I am realizing that while the holy grail is having students complete all of the challenges that they are issued, there are a lot of conditional or proxy metrics that will help us figure out the ideal conditions for challenge completion.  And once we’ve isolated those, we can work on tweaking design (on both technology and content fronts) to ensure even higher rates of success post-pilot.  One complicating factor in the short term is that we are tracking success and engagement differently for our two different constituencies: mentors and mentees.  For mentors, our hypothesis is that the more that mentors engage with the app, the more likely students will be to complete their challenges.  (This was largely informed by our prototype test — at first, we were entirely hands off.  We discovered that quick, small-scale interventions along the lines of: “Jeremiah, why don’t you share your #savings moment with the group?” truly worked and spurred increased engagement.)  So, in the pilot, we want to learn whether mentors are verifying challenge completion promptly — and how many log-ins a week it takes to do this effectively.  We want to match the number of “cheers” and “nudges” (whether through “liking” mentee posts or leaving a comment) to the relative engagement of their mentees.  And if these numbers are low, but student engagement is high, we want to learn how much the in-class experience affects this, if it all.  If mentors are disinclined to use the app, we want to know why and what would help them — texts? push notifications? emails?

4_student_main

 

{Sneak peek of student-facing app design for our Moneythink Mobile app.}

On the mentee side, we want to know how many challenges are begun vs. completed, how many challenge progress posts are submitted, how many likes and comments they are leaving.  If we see substantial attrition on certain challenges or on the challenge curriculum overall, we want to focus on those points and determine how to increase retention through challenge design.

On both sides, we want to learn which pages are most frequently visited — are kids skipping to the challenge rooms?  Should the app open there instead of their current home pages?

In short, there is a lot to learn from the pilot and I’m doing my best to isolate the most important features and to sort through the important pieces of data to collect now, vs. what to worry about later.  As Eric Dynowski, one of Moneythink’s incredible advisors and mentors and CEO of the Turing Group, told me on the phone this morning: “Better to have way too much data and to measure way too much to sift through than the alternative.”  A lot to learn here — can’t wait to share what I learn in a few months, once I’m done with my data bath!

Going Native.

One of the toughest decisions I had to make during the app design process was whether we were going to design a mobile-ready web application or a native application.  (Spoiler: we ended up going native.)  Having done a lot of hand-wringing and tossing and turning on the topic, I thought I’d share the framework I built for myself (on the fly) as I was weighing our options.

native

 

{Image via Sheridan.com}

Important caveat: there are no right or wrong answers here, in my opinion, which is why we’ve seen big companies like LinkedIn and Facebook go in one direction and then shift to another.  (Both of them began with mobile-friendly web apps and then went native.)  There are pros and cons on both sides, and this is a decision that requires a lot of careful thinking and balancing.  I asked myself the following questions:

1.  Will the app make use of native smartphone features?  (Or will the use of those features dramatically optimize the experience?)

Our app is designed to make primary use of the smartphone’s built-in camera — youth post their progress on most of their financial challenges by snapping photos and posting them to a “challenge room news feed.”  This design feature made the decision to “go native” fairly straightforward.  If you’ve ever been prompted to toggle between apps while trying to accomplish something in one app, you know how frustrating a non-native experience (i.e., without the camera API) would be.  (In my opinion, there’s nothing more frustrating and disruptive than clicking a link that then launches the Safari browser.)

In this fantastic article, mobile technology guru Michael  Mahamoff also makes the point that “smartphone users demand alternative surfaces such as widgets and notifications. While the latter is starting to get support in HTML5, it’s often difficult if not impossible to construct these UI surfaces from the browser, and even HTML5-powered native apps are limited in their means to provide rich, interactive interfaces outside of their primary arena.”  Though our minimum viable product will not include notifications of this kind, we envision that as we move to concept, this will be a crucial feature addition, as our target market (youth between the ages of 16 and 18) are accustomed to viewing a cross-application feed of notifications in their smartphone notification center.  I think this is an important observation that the tech world should keep an eye on — possibilities for notification “channels” are emerging.  As  this article points out: “Our portal is our app screen. Our network isn’t Facebook or Google or Twitter. It’s the phone address book that is the union of those three imports. And on the phone we stop dreaming about “If only there was a service that integrated functions of Twitter, Gmail, and Snapchat!” Because there is a service that integrates that — your phone’s notifications screen.”

I digress here.  But the point is — think carefully about the features of your app’s design.  Will it make use of the phone’s GPS?  Scan?  Camera?  Etc.  If so, lean towards native.

2.  Will the app have a complex UI?

Let’s be honest: all native apps will feel more elegant and rich than their web app counterparts.  If you question this, check out Facebook through your mobile safari browser.  Then remember that Facebook has hundreds of engineers who work on optimizing this experience.  That being said, there are interfaces that are on the simpler side and won’t be as dramatically impacted by the comparatively clunkier web app experience.  For example, if your app primarily consists of “static” content for reading/reviewing (for example, a blog or news syndicator), or maybe simple checkboxes to demonstrate interaction, then the mobile-ready web app won’t be dramatically improved in a native format.  If, on the other hand, your user will need to interact quite a bit with the screen or will be providing a lot of user-generated content, the equation changes.  For our app, youth will be updating a “challenge room newsfeed” with their progress.  Envision the clunkiness of a newsfeed refreshing every time you enter something new — possibly taking you to the very top of the newsfeed, or not showing new entries in real time.

If you want to get even more advanced in this conversation, note Mahamoff’s comment that: “The HTML5 “write-once, run-many” argument was more compelling when platforms lacked strong visual identity. A bespoke, run-anywhere, HTML5 UI could be just as good. These days, that’s just wishful thinking; Android, Windows, and BlackBerry have joined iOS as platforms with distinctive look-and-feel – and have discerning users who truly give a damn. So while HTML5 still aids reuse in some areas (subject to the fragmentation concerns mentioned above), user interfaces must be customised to build a great app. Even then, there are inevitably telltale signs and a lot of performance work that could be avoided in native platforms.”

3.  Are you planning to make frequent updates?

If yes, web apps are infinitely easier to update on the fly, and you don’t need to worry about version control.  You also don’t need to worry about app store approval — which, for iOS apps, can take days and even weeks.  (The Google Play store takes less time, but there is a process involved.)

4.  Are you trying to design something universally accessible?

If yes, web apps are likely the smarter route.  This was the biggest sticking point for me in my decision-making: in an ideal world, we would have come up with a way to provide the app to all of our students right from the get-go.  But our budget and contract only permitted the development of either a native app for Android OR iOS (not both) OR a mobile-ready web app.  It came down to weighing the pros and cons of getting the UX right with a native app vs. including all students with a web app.  At the end of the day, we decided that engaging students was more important.  We were worried that the UX would be so compromised in web app form that it might foreclose on our opportunity to engage youth longterm.  (N.B. One survey revealed that user engagement with a native app is 2x that of a web app.)

At the same time, the fact that only about half of our students will be able to use the app during our pilot this spring is admittedly imperfect.  We were comforted by the fact that, during our prototype test, student engagement largely followed cohort-specific trends and dynamics.  (That is — we ran multiple cohorts within three different classrooms, and specific cohorts within classrooms tended to vary with engagement — but not classrooms as a whole.)  We also saw that Android devices enjoyed a slightly larger market share, which made sense to me — there are a variety of different Androids at different price points.

It should be noted, however, that the web app route has browser segmentation issues — that is, browsers can be inconsistent in supporting HTML5, and you need to guard for these use cases.

5.  What are your budget restraints?

Native is always more expensive, especially because you’ll need to design for both Android and iOS (and potentially beyond…?)

6.  What sort of experience is your target customer accustomed to for this sort of product?

Youth are especially picky about design.  They’re much less forgiving than older generations, who have seen the idea of a native app come into existence.  We heard kids say: “If it’s pretty, I’ll use it,” and, on the other side of the spectrum, one student told me: “Craigslist is so ugly that I won’t use it.”  Our youth are accustomed to the rich, elegant native app experience.  I also felt that owning real estate on the smartphone would be especially important in terms of driving app use — would students remember to navigate to our web app when unprompted?  (N.B.  Users today spend almost 8x as much time in native apps than they do in a mobile web browser.)

7.  Will the app encounter difficulty in getting approved by an app store?

Something to keep in mind!

Send me your thoughts!