Tag Archives: tech

Pitch Perfect

Want to know if your team understands something? Ask them to give you the elevator pitch. If they can’t summarize the objectives and high-level milestones in a few quick sentences, it’s unlikely that they understand it very well.

Take a step back, can you give an elevator pitch? If not, take the time to make sure that you truly have a grasp on the plan, then take that newfound proficiency to get your team on board as well.

You’ll be surprised at how much traction simply having a firmer grasp on the subject will help your team gain!

White, Male Speaker Seeks Microphone

Another white, male conference speaker has sounded off about the “quotas” that are “stealing” “his” speaking gigs and “giving” them to women or people of color despite the fact that they are “inferior.”

In case my liberal use of quotation marks above didn’t sufficiently convey my opinion on the matter, this strikes me as absolute nonsense!

Continue reading White, Male Speaker Seeks Microphone

Leading Without Ego

The lede of an interview in which I was recently featured ended up being the notion of not being precious with your ideas—as a result, that concept has been the topic of conversation quite a bit over the last few weeks. As often happens, the most common question to arise also happened to be the most obvious one:

How do you avoid being precious with your ideas?

Continue reading Leading Without Ego

Confessions of an IT Pro: Precious Ideas Will Hold You Back

This is a placeholder for an article about me that was posted on a different site. If you want to read the article, you’ll have to click through! Please try to ignore the ginormous picture of me at the top. Please try to ignore the use of the word “Pro” in the title. Creative liberties were taken!

Unlike being a lawyer or a doctor, IT has a number of entry points. Some go to school. Some convert their passion from childhood into a career. And some, like software professional Jer Lance, initially get their training and expertise through military service. We spoke with Lance about his roles spanning education, management and software development and what he’s learned over that time.

Q: How did you start your career? And how important do you think education and certifications were for you? 

Read more…

You Get What You Measure

Wells Fargo has had to fire over 5,000 employees as it was found that they were making fake accounts on behalf of customers—these terminations took place over the course of a few years, so this has been going on for some time. More recently, however, the bank ended their program of incentives to cross-sell accounts to customers.

To recap: a company started to measure how often its employees were able to cross-sell accounts, applied incentives to that measure, and the employees dialed up their cross-sells to the point of actual fraud.

This is unsurprising, you get exactly what you measure—no more, no less.

I’ve seen this often in software delivery: companies claim to value quality, but what do they measure? Lines of code, features completed, project milestones, deadlines. What do you get in return for that measurement? You get tremendous amounts of low-quality work delivered on time and within budget—then you spend extraordinary amounts of time and money fixing all of the terrible, broken software you’ve created.

A past employer expressed tremendous amounts of frustration with exactly that problem when they brought me onto the team; their projects would be completed reliably on time or very close, but would often be delivered 100% or more late (and with tremendously reduced profit) because of the enormity of the repair tasks.

If you want to receive quality, that is what you have to measure. There are numerous ways to do so; incentivizing first-time delivery quality with zero-defect feature bonuses, tracking defect counts against feature complexity for a team, and turning off incentives for milestones in favor of incentives for active status communication are just a few that I have used with great success.

In the aforementioned company, I lobbied for and eventually succeeded in eliminating milestone measurement on the delivery side of the organization in favor of quality metrics similar to those above, and both profit and timeliness skyrocketed…but what rose the most was customer satisfaction. Suddenly, clients enjoyed our process and software, which was really my goal all along.

Remember that you will always get what you measure, but you will get the letter of it, not the spirit of it. Act accordingly.

You Get What You Pay For

One of the lessons that I find to be simultaneously essential to learn and incredibly difficult to teach is an idea that I refer to by the shorthand “being a consultant”–the notion of saving the customer from themselves.

Paul Sherman’s amazing presentation “The UX Unicorn is Dead” (if you haven’t read it, stop reading this and go read that) highlights an excellent opportunity to save the customer from themselves: customers asking to forgo UX or QA work (or, in some horrifying instances UX and QA work) in exchange for a lower price or faster timeline.

You get what you pay for.

Continue reading You Get What You Pay For

Leadership Doesn’t End

This post is a placeholder to an article that I wrote for another site, if you want to read the article, you’ll have to follow the link…

It’s 10am and I am sitting in my home office corresponding with a broad network of contacts and contacts of contacts, and it occurs to me that for a hopeless introvert, the last 24 hours amounts to more “being on” than I typically muster in even a busy week.
And I haven’t even started trying to find a job for me yet!

Fast Food Delivery

I’ve written and spoken on the subject of managing customers fairly extensively because I feel that it is often done incorrectly—no, not just incorrectly, but extraordinarily incorrectly, cartoonishly so. In my experience, most customer management is done from a place of complete fear. How do we avoid losing the customer, how do we avoid offending the customer, how do we avoid failing the customer.

So defensive. So reactive. So rooted in negative emotion.

Continue reading Fast Food Delivery

Manager vs Leader Talk at Penguicon 2016

Dawn Kuczwara (@DigitalDawn) and I talked a bit about the difference between managers and leaders at Penguicon this weekend. Penguicon always pulls a different sort of talk out of us, and this is no exception. The informality of the panel-style discussion lent itself to several things…

Continue reading Manager vs Leader Talk at Penguicon 2016

Moving to Agile: Training

I haven’t really had the mental energy to write much about our transition to agile for the last month or two because I have been spending so much of that time period putting together and executing trainings. Even with as much enthusiasm as I have for this, it has been a draining several weeks.

The human urge to generate complexity when something seems too simple makes teaching simple things a weird chore. When I walk someone through the thought process behind answering a specific Scrum question, it’s often perceived as too simple—I get wary looks from the audience as if I’m trying to trick them. There is no trick, it’s really that simple. Continue reading Moving to Agile: Training

Moving to Agile: Adjusting to Change

This post is the third in a series that began here.

It did not take very long for one of our projects to see its first curveball. As our client fell behind on providing information that was necessary for us to progress, we were in danger of running out of work. In our traditional waterfall model, that meant that we were stuck in a common position of having to pull the dev team off the project and delay the progress of the project—pushing the project day-for-day until we have what we need to move forward.

I must admit, it didn’t even occur to me to handle this a different way until someone said in jest, “shouldn’t this magical new process fix this?” Continue reading Moving to Agile: Adjusting to Change

Moving to Agile: Strategy

Over the course of the last 3 months, I have been coaching my team through a transition to scrum development. This hasn’t been simply an exercise in trying something new for the sake of something new; this move has been an attempt to alleviate the problems caused by years of technical debt and unsustainable work practices that have resulted in significant points of pain for our organization. While I would certainly like to get into the why (and that will almost certainly be a topic for a different post), I’d like to focus on some of the details as to how we have chosen to execute the transition. Continue reading Moving to Agile: Strategy

Moving Our Tools Out of Our Way

An interesting observation as I work with several teams to migrate a very waterfall process to Scrum: it is ridiculously easy to let the tools and the ceremonies become pro forma exercises rather than thoughtful representations of the spirit of what we’re doing.

I think that the biggest value I add as a coach has been to remind entire teams—regularly—to focus on the spirit of the manifesto rather than following the “rules” for using the tools or ceremonies. The tools do not define our process, the tools are there to facilitate our process. Something to remember.

Upgrading to Windows 10

I upgraded to Windows 10 this weekend on the only Windows system I use, my gaming system. I had it on good authority that the games that I’ve been playing occasionally were well supported (pretty much Guild Wars II) and that it was an improvement over Windows 8 (which, unfortunately, came on my system and I was too lazy to downgrade it).

Overall, I’m pretty happy with it. They got rid of the fullscreen start menu replacement in favor of a much more user friendly option that is a natural extension of what they had right in Windows 7. There are, however, some pretty significant privacy concerns, so right off the bat I did the following (most of which I document here in case it’s not exhaustive and for later reference):

  1. Privacy Settings
    1. General: Turned all off
    2. Location: Limited to only those apps that I want to see my location
    3. Camera: Limited to only those apps that I want to have camera access
    4. Speech, etc: Turn off “Getting to Know You”
    5. Contacts: Turn off “App connector”
    6. Calendar: Turn off “App connector”
    7. Feedback: Set to “Always” and “Basic”
    8. Background Apps: Turn off all but apps I actively use and want running in the background (Twitter, Dropbox, etc)
  2. Wifi
    1. Wifi Sense: Turn off “Suggested” and “Contact” connection
  3. Cortana
    1. Turn off Cortana
    2. Turn off search suggestions
    3. Turn off popular news
  4. Edge
    1. Save passwords: off
    2. Save form entries: off
    3. Do Not Track request: on
    4. Search suggestions: off
    5. Block all cookies
    6. Media licenses: off
    7. Page prediction: off
    8. Set Chrome or Firefox as default browser then never open Edge again

When to Hit the Gas

In my last post, I alluded to a set of criteria that I use to determine whether or not it is reasonable to ask a team to work significant extra hours—such as going over 45-50 hours in a week or working a weekend at all. What I didn’t do was describe the composition of that criteria.

I typically am looking for three factors to be met; so when I’m determining if it is appropriate to ask for the additional work, I look for:

Is there a defined, specific, goal? This doesn’t mean “finish the project,” as that is the sort of down-the-rabbit-hole trap that ends up dragging teams to an early exit. This means “we have these clearly defined tasks with clearly defined success conditions that must be done.”

Is the goal possible? My criteria used to be 2-items in length, until I was at a job that delighted in giving clearly defined criteria that were clearly impossible. Nobody should be sent on a death march.

Is the duration and severity reasonable? Saying “we have a clear, specific goal of working 80h weeks for no more than 2 months to do these 100 items” might be sufficiently specific and plausible, but the duration and severity virtually guarantee that quality is going to be thrown out entirely.

These are not the only factors that I consider—length of time since last the developers involved have been asked to do this, how did we get in this predicament in the first place, is this a reasonable thing to ask to get us out of the predicament; these are all also considerations to varying degrees—but the above are the primary drivers of my decision making.

In practical terms, this is handled as a conversation. By way of example, on projects for my current employer, working considerable extra time was brought up in two distinct situations on two separate occasions. In both instances, I sat with our senior management team and walked through the above thought exercise.

In one instance, it was determined that while the scope of work was relatively well defined and possible, the duration of the overwork would be such that it was very likely to destroy quality. It was also likely to have a significant impact on the development team as a whole. In that instance, we decided together that it wasn’t worth the risk, and found a plan that would yield more reliable results.

In the other instance, while the same risks were very much present, the volume of work was more reasonable and we all felt comfortable in using over-work as a strategy.

In both cases, working together first with my management team then with my development team was an essential piece of the decision making process. It has been my experience that this criteria has both served as a gatekeeper for preventing burnout and low quality due to overwork, but it has also served as a educational opportunity for all involved every time it has come up.