Kill your piles

I am a notorious stockpiler. I like to be prepared. Use the last of the toothpaste? Don’t worry. There’s 2 more in the closet. That’s not the last of the napkins, that’s just the last of the pile I have out on the table for convenient use. I get anxious when there’s less than 4 rolls of toilet paper in the house.

I justify these actions by telling myself it will all get used eventually – after all, I’m not saving old newspapers “just in case,” or refusing to throw out broken items. I’m no hoarder. It’s just a backlog of things I will certainly eventually use.

Or, more accurately, things I would certainly eventually use if I weren’t also constantly restocking the stockpile.

There’s a certain sense of comfort in having that backlog. I had a team member who would never finish his work, never clear out his backlog of tasks. I’d get so frustrated, feeling he was constantly behind, while he felt a sense of security by always working just enough to get his backlog pile to roughly the same size by the end of every day.

Ultimately, a pile is waste – it adds no value. If I constantly have 2 tubes of toothpaste in the closet, one of those will never be used. If I have 20 tasks stuck in testing, then I’m wasting developer time on new tasks because nothing is going out to the client. There is no value in continued development because there is no end product for the client. Wherever you have a pile, wherever you have waiting, you have waste.

The only thing a client can value is something they receive. You’re not adding any value or “getting ahead” by continuing to throw tasks on the testing pile if nothing is leaving the testing pile. How many tasks do you have waiting for “just one last thing” before you ship it off to the client? Why are you starting new things before shipping old things? You’re just making an enormous pile of old things waiting for completion while you get distracted with the shiny new things.

Where are you piles? Go kill your piles.

Except for the toilet paper stockpile. You’ll totally need all of that someday.

Scarcity and Abundance

There’s a theory in this book that, while too little of something may be a bad thing, too much of that thing may also be bad. That more is not always better. It’s only better to a point, and then the benefit may not only level off, it may actually decrease.

It’s a U shaped curve. Benefit rises as you climb out of scarcity, and then benefit decreases as you head into abundance.

An example might be class sizes. 50 kids in a classroom is too many – the teacher is spread too thin, you can’t pay attention to everyone, people get left out, chaos ensues. On the other hand 5 kids in a class is probably too few. There may not be enough difference of opinion to get any real discussion, there’s not enough diversity of thought.

Another example – income.

If you’re working multiple jobs to make ends meet, you simply can’t afford to give your kid anything they ask for. You likely end up teaching your child that they can put in hard work and earn the thing they want – they learn the value of effort and reward.

But at some point on that curve, the parent has plentiful income and can easily provide whatever thing is desired by their child. Here’s where things get difficult again. You have to say no because of your values, not because of a lack of resources. It’s easier to say no when you don’t have the ability. It’s harder to say no because of your principles.


It made me think about scarcity and abundance and my own values at work. When we have an abundance of time, do we still live our values?

If you don’t really have to complete a task until the end of the week, but you say you can get it done on Tuesday – do you really do it on Tuesday? Or do you let it slide because you can, given the abundance of time?

Do you tell a client ‘no’ for an early scope creep item that is small, when you still have an abundance of time and budget, based on the principle? Or do you agree, sidestep the difficult conversation, and allow it to slide?

Abundance allows us some generosity, but scarcity can forge your values. Are you living the same values when times are easy, as when they are hard?

Are you my leader?

If you asked me what I’m good at, I’d say administration. I’m not always the big idea person, but I know how to get big ideas done.

I’m reading this book about leadership, and I’m no where near as comfortable with that moniker. Am I a leader? I lead my team, surely. Why don’t I think of myself as a leader?

I keep coming back to these agile concepts of scrum, and the concept of myself as a scrum master. The facilitator of a self-organizing team. The scrum master isn’t really responsible for setting tasks. They don’t pick who does what. They just facilitate others, they define process and help the team implement those processes.

And then I think about a leader. Someone who sets the task, sets the standard, makes decisions, and is the source of team accountability.

Where do leadership and scrum mastery intersect?

It almost feels like socialism vs democracy. Old testament vs new.

There’s the concept of the ‘servant leader’ as scrum master, which covers this seeming dichotomy. In theory, everyone is accountable to the team, and the scrum master is responsible for maintaining process, but not the implementation methodology of that process. But in my reality, I have to chase after people for time sheets, I have to conduct reviews, and I’m accountable to leadership for standards that may or may not be different than the standards of the team.

I suppose this whole post is just thinking out loud. I am drawn to act in service to the team, and yet there are times I must lead. How do you draw the line? How do you set clear expectations? How do you keep that from sending confusing or mixed signals to the team? Where’s the middle ground – and is middle the right place to be?

Perhaps answers come with time and trial. Onward!

Believe the actions, not the words.

In many ways, I’m an idealist. An optimist. I want to believe the best in people. People are nice, respectful, and well-intentioned. Their words match their actions. There are not hidden agendas. In my world, high trust is the default mode of operation.

I maintain this perspective by never reading comments on anything online, clearly. I ask you to afford me my idealistic beliefs.

I’m proud of them, quite frankly. I believe in my team, in my clients. I want to believe and foster the best in people. I believe in clarity of intent, in honest, open discussion, and in the presentation of a true picture of where you stand and what you represent.

I don’t want to be jaded and cynical. I want to believe. And at the end of the day, I want others to believe in me. To see the congruence between what I say and what I do. I refuse to stop kicking when I’m put in a position where actions don’t match stated values. I will carry my little naive torch, and be an example of what I expect to see in others.

It’s not always easy to live your values. Perhaps I just needed to remind myself of that today. Being accountable is a beautiful thing.

There’s nothing stopping you.

It’s one thing to have an environment where an individual’s initiative is not discouraged. Where if your team member goes out on their own to implement a new idea, they are not punished.

It’s quite another to foster an environment where initiative is perceived as desired. To make a place where your team is cultivated, strengthened, encouraged, rewarded, to invest yourself deeply in the success of your team.

I think about team culture quite a bit, being on two teams myself – one as a leader, one as a team member. Having the benefit of both managing and simultaneously being managed, you get a different perspective on your own theories of leading a team. You see both sides of the coin, you live both sides of the coin.

This week, I spent a lot of time thinking about how to cultivate an environment where people are encouraged to solve their own problems, where they feel safe, but are consistently challenged to learn and grow and try new things. Where failure to succeed the first time results in encouragement, not punishment.

Without insincere superficial praise, without masking real problems with new distractions every week – how do you keep a team challenged and encouraged to go out and experiment a little?

How do you get a team beyond having to point out to them that no one is stoping them from trying that new idea, to a place where, when an idea occurs, the top of mind response is to feel encouraged to try it?

That’s a big swing. One environment is all about fear of risk, fear of punishment and failure. The other environment is embracing the possibility of failing, recognizing it as an opportunity to learn, and moving forward fearlessly.

Which are you creating with your actions? How do you react when someone on your team fails? What are you doing to foster and reward those that take initiative?

On Motivation

I have this little cube on my office desk. It’s a timer. You flip the cube over so that a number is on top, and then it beeps after that many minutes have elapsed.

This is useful in many ways.

Got a meeting in 15 minutes? Flip the timer to 10 min. You can ignore the clock and safely work on whatever you’re working on for 10 min. When it beeps, you have time to save your work, get a bio break, open your calendar, and get to the meeting on time.

Need to get up and stretch every hour? Flip the timer to remind you to stand up and walk around every so often.

My favorite use is sorta like the Pomodoro technique. When there’s something I’m dreading – answering a stubborn client email, writing ridiculous status reports, cleaning the house – I set the timer for 10 minutes and I just… start. How bad can 10 minutes be? Surely you can endure 10 minutes. Just start the stupid thing. You can quit in 10 minutes.

Usually, 10 minutes is enough to make decent headway into the task – as a project manager, I do a ton of smallish to medium tasks. Usually, 10 minutes is enough to prove to myself that this task wasn’t so bad after all. And usually, I’m done shortly thereafter.

The problem comes when you’ve already reached into your bag of tricks a dozen times, already pulled out the cube and every other tool you’ve got to get stuff done, and you still come up short in the motivation department. When you’ve exhausted your resources, and you don’t feel any better after your 10 minutes is up.

What then?

You put your head down and you slog through.

It reminds me of shoveling snow. (As if this post needed more tangentially related stories.)

In Rochester, you ain’t driving anywhere until the snow gets shoveled. And it’s no fun. And you’re tired of it after 10 minutes. But it’s got to be done if you want to eat something other than mayo, a jar with 2 pickles left, and snow for dinner.

And then the slog method fails. It’s not sustainable. You start to lose pieces of your soul, forcing yourself through the motions with no heart.

Something has to change.

Will it be you? Or your situation? Or both?

Paperweights and Change

I’m sitting at home, watching these big fat flakes of snow fall, waiting for a call. We’re currently a 1 car household, the other car having just transformed into the world’s largest paperweight in the parking lot of Wegmans. We’ll head back to meet the tow truck driver when he calls to say he’s on the way.

This morning, the forecast said to expect 5-8” of snow. Now it says only 3-5” of snow.

This morning, we had 2 functional cars.

Life is change. It’s an adventure that we can influence, but rarely ever truly control.

As I opened my laptop just now, my browser was open to a conversation in a Project Manager group on LinkedIn about dealing with unauthorized change. The responses are generally insisting that unauthorized changes don’t happen in a properly managed project. That clients present a Scope Change Request, or they go through the Change Control Board, whatever that is. Or to stop all work until the change is authorized, and to punish the offenders swiftly.

The stark contrast between the rampant idealism in this conversation and the reality of projects is stunning.

What a disservice to our peers, to our teams, to our management – to pretend that our influence in the realm of controlling all aspects of a project is complete. We’re not managers. We’re shepherds. We guide, we influence, we provide direction. We attempt to clear the path, to avoid obstacles. But we’re not really in control.

Change is coming.

So is the tow truck. We hope.

Failing at Full Screen February. Already.

5 minutes into my first meeting, and I’ve already failed at Full Screen February.

I was mostly on the meeting to report on any status questions asked, while the account managers negotiated a contract. And so I busily applied myself to organizing a different project for the week, while they discussed.

And then I realized what I was doing. And that it is already February. And that I had better pay attention before one of my team called me on my behavior!

The lure of the second monitor is strong. I managed to finally ignore it, but then I wanted to pick up my pen and start a todo list for the day. I kept picking up my pen and putting it back down.

So fidgety.

I sat down at 10pm last week – not tired enough to sleep, not wanting any screentime – and picked up a book. It’s a book I’ve read before, and enjoyed. It was so hard to get through even just a few pages. The author writes in a style somewhere between sparse and flowery – descriptive, setting the scene, adding information to build the mental image, but not really integral to the plot.

And so I kept skipping forward, waiting for the next sentence that would further the plot. I kept having to stop and re-read. I mean, if I’m reading the book, I should *read* the whole dang book. It was so hard to make myself stop and look at every word, to not skim, but to take it all in. I got so frustrated with myself, with my lack of focus on the one thing I was trying to do.

Full Screen February will be harder than I thought.


Full Screen February

You know what is really irritating? When you make the effort to get up out of your car to walk into Starbucks, and then the people in the drive-thru get served before you do. I mean, you put all that effort into actually stepping foot into the store, to really *be present* with your barista, and then they serve some lazy jerk who couldn’t even get off his butt to get out of the car before they serve you?

How rude.

I should mention I’m in a meeting right now. I assume there are things going on in this meeting that I should be paying attention to, but I’m totally distracted. I just got a flood of Jira emails, a got a developer pinging me on Hipchat to tell me to go tell this other vendor to fix their stuff, I’m only halfway done with the things I wanted to accomplish today, plus, well. I’m writing a blog post.

Turns out that I’M the lazy jerk in the drive-thru.

Hold on, there’s some kind of awkward silence in this meeting, I need to see if they just asked me a question. BRB.

Okay, I think I bluffed an answer pretty well there. Where were we?

Oh yes. Me being a lazy jerk.

It’s too easy to not be present on these meetings. To be on a video chat and not even be looking at the other people on the meeting, to be staring at my second monitor, to be typing emails or checking messages, or using the time to catch up on something else.

And that’s not fair to the other people in these meetings. If the meeting is worth my time, then it is worth my complete attention. If the meeting isn’t worth my complete attention, then I need to not be in that meeting. Simple as that.

I’ve decided to try to mend my distracting lazy ways, or at least forge a better habit of paying attention, and treating these meeting attendees as the valuable contributors that they are. So I’m declaring Full Screen February for myself.

Full Screen February means my meeting is full screen. It’s my full attention. No other windows open, no checking email on the side, just the one thing to focus on on the screen. One full screen meeting, focused attention.

Maybe I’ll learn I need to cancel some meetings.
Maybe I’ll learn to run a more efficient meeting!
Maybe I’ll get better connection and better problem solving out of these meetings.
Maybe I’ll learn to set more accurate priorities for my attention based on real value of the things that compete for my attention.

Either way, it’ll be a challenge. Full Screen February. Are you in?

A Discourse on No

I’m a member of a few Project Manager-ish type groups on LinkedIN. Recently, there was a big discussion about how to say No to a client. Some of my favorite answers from the discussion:

Just Don’t Say No
Use data and options to deliver the message instead of outright No to the receiver.

Threaten With Dire Consequence!
I find the best approach is to provide the consequences of saying yes to the person, party, group involved. Then asking them if you say yes which consequence are they willing to accept. If there are none then they will come to the same conclusion as you and they will tell themselves ‘No’.

Of course making sure the consequences are substantial is the key.

Make Jerky Assumptions
Unless it’s a true emergency situation, approaching “NO” as if it were a “YES” can usually deflect the request. Just select one of the following approaches.

1) Sure we can do that, what function(s) would you like us to remove so we can remain on budget and schedule?
2) Sure, I’m sure the senior executive won’t mind that we delay the project just for your request
3) Sure, can you give me your departmental charge code so I can start charging time to it.

You get the point.

By that time they will have figured out that the request could wait.

Agree and Back Out Of It Later
It’s quite difficult to say NO to local client however I always say “I will try”. Afterward I will send email explaining why it cannot be done and explain the impact if we still want to do it. It works most of the time for me

Start with the findings.

“The combination of factor after due diligence was done…”

And finish with

“Will regrettably lead us to conclude it is not possible/feasible/advisable/… To do what you require/need and hence our position is to cancel and reassess”

It Wasn’t Me!
I generally find a straightforward “no” accompanied by a brief explanation as to why not appeases most people. There will always be the difficult ones who still find it unacceptable, but I can usually pass the buck upstairs when that happens. These people soon learn that the “no” hasn’t come from me personally, but is an informed and calculated business decision backed by our Management Board.

But this guy nails it. If you’re going to say no, then just do it. Clearly, simply, honestly. Being direct and clear builds so much trust. No hiding, no pretending, just real communication.

“No” is an awesome word. It has HUGE impact when stated bluntly, because so many people actually AVOID using it in favour of long, convoluted explanations!

“No, because…” is a good way of getting the message of “No” across, with an element of softening of the impact of the (negative???) word.

We’re all aware of the emotional impact of being told “No”. So, qualifying the “No” with information that is relevant, focused, and of interest to the receiver, retains a lot of the impact of the “No”, while keeping the emotional response controlled (to a degree!)

I’m a big fan of the word no. Even hearing it.

I appreciate it when a supplier tells me “No”, instead of giving me some long explanation as to why a delivery/activity is not going to come in on time. The emotional response of hearing that long explanation (Frustration? Disappointment?) causes me more grief than the shock of a straight “No”. You can get over a No, and put a plan in place quickly.

Dealing with one of these explanations usually turns into a battle of wits, where you, the customer, is trying to tease a blunt “No” out of the supplier anyway!

I could write about this for days…

Ain’t language great?!? 😉

Empathy, Engineering, and People

A discussion of empathy in engineering:

Erin Cech at Rice University agrees that empathy is essential and names our current culture in engineering a ‘culture of disengagement,’ one in which engineers focus almost exclusively on technical details with little or no attention to empathy and moral issues. Cech’s recently published results show that engineering students’ level of empathy decreased over the four years of their engineering education. Yikes. Not only are we attracting students with lower empathy to begin with but they become less empathizing over the years of their engineering education.

Why is empathy essential in engineering? Engineers design and build products, yes, but these products are for people! To design effective products and processes engineers must understand the people who will use them.

[emphasis mine.]

For all of the focus on technology, on building things faster, more efficiently, it’s all for naught if it doesn’t serve the user’s needs. If we’re not solving someone’s problem, then what’s the point?

Product Maintenance

Ah, product maintenance:

Working with talented people who are constantly learning is amazing. Thinking that every piece of code that is even slightly aged is incorrect or wrong is not as amazing.

Compromise is a skill. And not one that we only use with clients. 🙂

A well-oiled decision making machine

I’m helping a buddy with his site, doing some analysis of the analytics to see what’s working and what isn’t, and to try to identify some places where he could bump up the site’s revenue a bit.

The whole things feels quite luxurious. It’s a side project for him, and I’m just doing it for fun, so there are no timelines, no pressures, just long, leisurely dives into some data.

It feels so decadent, this abundance of time.

It makes me stop and realize just how fast the team really moves some days. How quickly we encounter information, analyze the options, make choices, and then DO. Problem, data, tradeoffs, choice, action. We run through that at light speed, dozens of times a day.

Over time, I think it’s made me and my team incredibly efficient problem solvers. We focus in on exactly what is happening. They bring the technical information, I bring the product and client knowledge. We weigh options, pick, and then DO. Clean and targeted, and ending with action.

We should spend a little more time reviewing our choices and actions, but overall, I’m pretty proud of this little decision making machine we’ve created.

Is stress time over yet? I feel like it should be over now.

I think we are defined by who we become in a crisis.

When we are under stress, when things go wrong, when you’ve made a mistake, when the unexpected happens. Our reaction in times of trouble can be telling.

Do you take action to fix things, or do you just talk about fixing things?
Do you figure out what went wrong, or do you try to forget it ever happened?
Do you own up to your mistakes, or do you sweep them under the rug?
Are you interested in solving problems and fixing things, or are you only interested in who’s to blame?

Stress strips away all the pleasant veneer of interactions, and you get down to the center of who you are. It’s not always pretty what you find there, but I think it is an important place to visit occasionally.

But only occasionally.

I feel like I’ve been operating from that crisis stress center all week, raw and angry and frustrated. It has been a challenge to temper reactions to events that normally I would handle in stride.

How do you heal over-stress? How do you put back the protective layers of normality, of things going as planned, of occasional wins and compliments?

And more so, how do I ensure my team gets those things?

Don’t be a silo

I know this is a joke. An intended exaggeration. But it is frustrating nonetheless.

As I was watching a show on Hulu last night, this commercial kept playing for an online K-12 school. One of the “students” was saying how awesome it was that she could do 5 classes in one day on the days she felt like doing a lot, and none on the days she didn’t.

Which is great. But then it kinda isn’t.

That’s really not life, for most of us. We don’t get to do whatever we want to do, and only when we want to do it.

We work together. We accomplish things as teams. We need other people to support and inform and help us, therefore we must do our work at roughly the same time to be efficient. Just because you don’t feel like doing your work on some days doesn’t alleviate your responsibility to do it. Your team is counting on you, so you do what you need to do on the appointed day.

Perhaps it was just the combination of this illustration and that commercial, but I got peeved. I feel it furthers the notion that developers are delicate flowers that should never be interrupted, that their concentration should be preserved above all else.

I totally agree that devs need long uninterrupted stretches of time to do work to be most efficient. And I strive to provide that. But to be effective as a team, you have to be willing to stop and talk to your team. And the daily standup is that method.

Sometimes, you have to subjugate your individual needs to better the team. That’s what a team is all about. Being pissy about a standup means no information gets transferred into other brains, which makes you a silo, and if you go on vacation, the work comes to a halt because you couldn’t take 15 min a day to have a very short conversation. You are not that important, that you should be able to bring a team down by taking a vacation.

Do the standup. Support your team. Don’t be a silo.

Proactive, not reactive

I keep a little note on my desk at work to remind me of the one thing I need to be above all else:

Proactive – not reactive.

This post was in my feed reader today, and I appreciate the message. Sometimes, we are so busy running around fixing the consequences of problems that we don’t ever get to the solving part of problems. It is stunningly easy to get caught in that mode.

It’s a daily effort, to stop and think – what am I reacting to, that I should be taking the time to solve and keep from happening again?

Finding, feeling, fixing friction

Without my intent, empathy tends to be a recurring theme for me here. I love this:

In the UX field we talk about a lot of things. Tools, processes, research, design, etc. But it’s easy to forget that a lot of those things are supposed to be ways of finding, feeling, and fixing friction and pain points of the people you’re trying to serve. Recognizing moments when you feel as others do are good reminders that all the work we do – no matter what our specialties, strengths, or backgrounds might be – has a common throughline: Empathy.

I do very firmly believe that taking care of your client’s experience, anticipating and fixing their pain points, is the key to success. And the same goes for your staff – take care of your people. The rest will follow naturally.

Get used to being uncomfortable

After going through the Certified Scrum Master class (I am fancy now!), I’ve been re-evaluating how projects are ‘managed’ at work. We are not fully agile, but we’ve been slowly applying some of the agile concepts and structures to our workflows. In an agency environment, where projects are fast, furious, and many at the same time, there is not always the luxury of doing full scrum processes.

In addition, I play both Product Owner and Scrum Master, which is less than ideal. I represent the client’s interests, prioritize backlogs, and also try to help the team organize themselves for delivery, remove their roadblocks, and basically keep them running smoothly. I think I play Product Owner well. But I’ve realized I’m not an awesome Scrum Master right now.

We need to shift towards more team choices where the team decides what to do next – I’m trying to adjust my phrasing and my approach to conversations so that the team feels more empowered to make choices on their own, that they don’t depend on me to tell them what to do. It’s an interesting shift. I feel like I’m forcing them to take more control – and that they don’t always want it!

It’s a good transition, and a necessary one as well. The process is a little bumpy, but we’re getting there. I have this vision of a group of awesome people who can discuss issues, make choices, and perform to their stated expectations all on their own initiative. A group that can control their own environment, and that feels not only empowered to make change, but a group that feels the ability to change and improve is their opportunity and obligation.

We’re gonna get there. Strap in and hunker down. We’re gonna get used to being uncomfortable. It’s a price of change that I’m willing to pay.

Master the basics first

Very good advice:

Until you can reliably deliver what you thought you could deliver, focus on how you define and build software. You don’t need Lean or Kanban or to improve your stand-up meeting. You need to learn how to define, build, and deliver software.

Don’t be distracted by nuance if you can’t get the basic gist correct. Deliver what you say you will deliver. And only work on that until you can do it. Be functional first. And then work on refinements.

The cost of gaining knowledge

Somewhat cynical, but amusing:

Every programmer starts out writing some perfect little snowflake like this. Then they’re told on Friday they need to have six hundred snowflakes written by Tuesday, so they cheat a bit here and there and maybe copy a few snowflakes and try to stick them together or they have to ask a coworker to work on one who melts it and then all the programmers’ snowflakes get dumped together in some inscrutable shape and somebody leans a Picasso on it because nobody wants to see the cat urine soaking into all your broken snowflakes melting in the light of day. Next week, everybody shovels more snow on it to keep the Picasso from falling over.

There’s never enough time, right? This world moves so fast. Even if a client had granted unlimited time to produce something (I can hear you laughing. Stop it.), the technology changes so fast that as soon as you build something, there is already a better way to do it. By the time you build your fourth feature, you already want to rewrite and optimize the first one you built.

But beyond the speed of technology, it’s just the cost of gaining knowledge. The more you know, the more you realize what you’ve done before could be better. It’s an awesome monster that we feed with every step. The faster you learn, the more the past haunts you. The refactoring monster is on your doorstep. Would you want it to be any other way?

I wouldn’t. The adventure of learning and exploring is worth the potential regret that we can’t refactor everything behind us.