Category Archives: Management

Attitude-adjusting pointers for professionals

Posted on by
1

Over the years, others have shared a few attitude-adjusting pointers with me about work. They’ve stood the test of time for me in a number of different jobs. Here they are.

1. Remember, you don’t need this job. You need a job, but not this one.

In my first full-time, salaried position, my boss shared this nugget of wisdom with me. (He shared the next one too.) I had to chew on this one for a bit, repeating it to myself in different ways for it to sink in. But once it did, it changed how I looked at my job.

The biggest change is that it removed a fear. I didn’t fear losing the job, because, after all, I didn’t need this job. With that gone, my attitude shifted to where I was willingly giving my time to the job. It was my choice to work there, so in a way, it gave me back some power, emotionally. I wasn’t dependent on the job, and I wasn’t begging for the chance to do that job. Instead, I had the freedom to focus instead on what I needed to in order to get the job done.

It also has helped me to not worry about the inevitable politics of an office, and instead more clearly relate to the people I work with. It helps me better respect my colleagues as the human beings we all are.

There is a simple, yet powerful, proverb that stands hand-in-hand with this pointer: “Do you work heartily as for the Lord rather than for men.” Attitude-wise, taking this proverb seriously means that I crave honor from God, not from my boss, coworkers, clients, or employees. This has been profound for me, and I encourage all who read this to take this proverb to heart.

This first pointer is probably the biggest of these for me.

2. If you want to seem invaluable, find a problem and solve it. See a vacuum? Fill it.

This one is obviously simple, I think, but sometimes I wonder if it just hasn’t occurred to people. If you want to be valuable, do something valuable. Keep your eyes open for that thing that clearly needs doing that you have a shot at doing, and figure it out. If it happens to make sense with your job description, great. If not, just do it anyway.

3. A secret part of your job is to make your boss look good.

This is an interesting one because it still applies when you aren’t happy with your boss.

How do you do this one? You give your boss credit for good work, good decisions, whatever, to others. You don’t have to overdo it, but keep it in mind. Also, I’ve been in situations where I’ve been asked to help prepare a presentation or a proposal for my boss, and even though I may not be the one delivering the presentation, I can try to make sure that my boss will seem  organized, coherent, and smart.

This pointer is helpful because, by making this part of my job, it forces me to check myself when I have a bad attitude about the person I report to.

4. Bring an alternate idea along when you bring a critique. (And if you can’t, then think twice about offering your critique.)

The point of feedback, of critique, is to make something better. I get the feeling that people forget this, and think that the point of critique is to look smart, to make someone else look dumb, and to thrill in the dark joy of shredding someone else’s work.

So, if the point of critique is to make something better, doesn’t it make sense to point out a problem and immediately follow it with at least one idea to overcome that problem? Maybe it isn’t the idea that will be chosen, but by offering that idea, you make yourself a collaborator with the person who receives the critique. You offering an idea can spur more creative thinking on the problem. Plus, offering an idea is brave, because your idea can now receive critique. If all you ever do is critique but never add ideas, you’re probably a coward and are making things worse, not better.

Closing

I know there are all kinds of other thoughts on work that I have, and I’m sure many of my blog readers have their own life lessons to share.

Please comment with your reactions or additions!

UX and Project Mangement cross-over article from Interactions magazine

Posted on by
Reply

A Taxonomy of Models Used in the Design Process by Joanne Mendel in the Jan + Feb 2012 edition of Interactions magazine is pretty interesting.

At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

Does Kanban hurt Agile teams by decreasing iterative development?

Posted on by
3
Workers welding on an automobile assembly line.

Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?