This post now lives here: Cheap and Bad versus Expensive and Good

This post can now be found here: Four Considerations of “Urgent” Work.

This post has been moved to: And Then What Happens?

Progress-Making Forces and Progress-Hindering Forces are in competition for the attention of your users. Those forces either push your users to a new behavior, or leave them stuck with the existing behavior.

(source)

IT may push a situation forward - to eliminate old technologies and legacy code. But too often that push is the only lever used. The user resists because of their allegiance to the existing behavior and fear of the new solution. They aren't shown the benefits of a new solution, so there is no pull toward the new idea. We're stuck with a Lift and Shift.

Manager READMEs have been an on-again, off-again thing over the last few years. The negatives are mostly because the author can't see their own weaknesses and over-value their strengths. Many readmes are long and rambling. Mike Crittenden suggests, instead, writing a 50-word personal readme:

You get 50 words, that’s it. It’s a forcing function to kill the fluff and decide what people must know about you.

What might I write? How about:

• Written over verbal
• Long-term over short-term
• I offer trust first
• Don't lie to me
• Bad news doesn't age well
• Team over individual
• Remote-first
• We're professionals and adults

This post has moved to: Bad News Does Not Age Well.

Marcus Blankenship recently sent an email on the stories leaders tell to “illustrate [their] values, pass on (usually painful) lessons, or communicate key points”:

Have you ever thought of your stories like this? Your winning stories, losing stories, and the stories of how you overcame adversity? Stories that inspire, or act as a warning to others?

I feel like I tell long rambling stories to my team, primarily to entertain. I like to think they inspire, but probably not. Marcus suggests a way to make better use of our stories:

You might sit down and make a list of some of the stories you’ve found yourself telling as you lead your team. Creating a written story inventory is a great way to see them with fresh eyes, and you might find new, fresh perspectives on them.

This article now lives at Being Glue.

Here are some of my favorite podcasts:

Company

Leadership

• Effective Engineering Manager
• The Important Thing with Michael Lopp (aka Rands in Repose)
• Level-up Engineering. A deep look into engineering leadership.
• Manager Tools and Career Tools.
• Soft Skills Engineering. A humorous look at the non-technical skills of software engineers. The hosts always have the great advice of "quit your job".

An idea: Give your documents an expiration date.

It's somewhat common to include a "written on" date in documents. But what about an expiration date?

If you're reading a document and it has expired, it is your responsibility to determine if its contents are still correct and valid.

Correct means the contents are still an accurate representation of a system, and valid means the document still applies to the current business environment.

This post has been moved: One-Off Apps.

This article now lives at Map of the Universe.

This article now lives at The Three Perspectives.

There are four areas of authority in a project:

• Budget Authority
• Requirements Authority
• Design Authority
• Technical Authority

We reduce frustration and confusion when we understand who has the authority in each area.

(source: The Art of Project Management (pp 42-43))

The company I work for took its strategic goals and wrapped them around the five core areas we focus on to create a strategic bullseye. This visualization helps everyone in the company understand what our mission is.

I use a modified version of the strategic bullseye to help my team understand where a specific project fits into the grand vision for our company. It can be hard to see how tech projects help the company as a software engineering team.

In the project charter, I highlight the strategic initiatives this project impacts.

When we're trying to rathet down the scope of a project to meet a budget, we're often prone to talk about "Phase 2" or "Phase Next" where "next" is whatever incremental number we're at.

But how often is it really "Phase Never"?

Is there already a planned budget for Phase Next? Have we already added Phase Next to our Capex budget? If not, it's Phase Never.

Honestly, Phase Next is just an excuse for the consultants we've hired to skip the hard work we can't afford right now. We all know we always pay full price, regardless of what phase the features we need are in.

Be careful your project status doesn't become a watermelon:

From the outside, the project status is green, but once you dig into it, it's red, red, red.

When someone offers you coffee, ask for it "black."

There's no search for flavored creamers or special blue packets of sweetener. You're making things easier.

In what ways can you simplify work for your team, your peers, and your customers?

Your willingness to accommodate their work is empathy, and they will notice your desire to keep moving forward. You're not people-pleasing; you're a "no fuss, no muss" sort of person.

I worry—more than I should—about uncontrolled documents getting sent through corporate email. Documents should be like the immortals from Highlander:

Whenever possible, I put my documents on a shared drive and share the link. This is especially true when there is the expectation of collaboration. We don't need to spend time reconciling four different versions of a spreadsheet. Should I need to attach a document for someone without access to the shared resource, I'll send a .pdf: it's read-only.

It is easy—at the optimism of a potential flawless deployment—to forget to let the support team know you're deploying new software. However, that's the team will be the first to hear about the weird new bug you've introduced. Make sure the help desk is part of your deployment communication.