Skip to content →

Category: Misc

Manager README

I had previously written a post called Guidance for My Staff and during a recent walk on the beach as I try to do every day at lunch, I was listening to Rand’s podcast The Important Thing and learned about the concept of the manager readme. The concept is more fleshed out than what I put together, so I’m working on an updated version.

Brennen at has collected a number of readmes from around the internet at that I am using for inspiration.

Comments closed

Guidance for My Staff

I’ve been managing software development teams for about 20 years at this point and have developed 3 primary guidelines.

Don’t surprise me

I really don’t want to hear bad news that you knew about from someone outside our team. I’d rather hear from you that something is about to go wrong so we can figure out the best way to deal with it proactively. Things do go wrong – sometimes caused by you and sometimes not. I’m not interested in fostering a blame culture, rather a “how do we fix this” culture.

This hold true for promises you’ve made as well. If you said you’d be done on Friday and Friday comes and goes, I’m not going to be happy. After all you gave me the timeline. If you come to me on Wednesday and let me know that you are not going to make the Friday timeline for <insert reason> then we can discuss the impact and and how to mitigate it.

Loop me in

One of the primary jobs of a manager is to be the line of communication with the rest of the business, both into and out of the development team. That is why we spend so much time in meetings – either gathering or dispersing information.

My specific guidance is to CC me on any communication that isn’t internal to the team. Emails to the VP of Basket weaving? CC me. Emails to that vendor’s support team? CC me.

Why? Mostly because I don’t want to waste your time or mine asking you if you responded to that email. Since there is a zero cost way to keep me informed take advantage of it. It also lets me know if I should step in should things spiral out of control. Mostly I’m a silent bystander.

Take a moment and think

I have an open door policy (a virtual door these days). I want you to come in whenever you’ve run into an issue. Not that I’m all knowing and can give you an answer, but I’m happy to work it through with you. The mere fact of verbally trying to express the issue will often trigger new thinking.

However, before you come to me I want you to take a moment and think. The saying I use is:

  • One idea isn’t a choice
  • Two ideas are a dilemma
  • Three ideas are a choice

Software development is a nontrivial activity within a company of any complexity, which is why most of us enjoy it. When I hire people I treat them like professionals and expect them to act like professionals. A big piece of that is recognizing that software fits into a larger puzzle and other people depend on us doing our job well. That builds trust, and trust can overcome the occasional bump in the road, especially when there is good communication between all parties.

And that is the crux of the 3 guidelines – communicate and communicate well.

One Comment

His nightmares with engineering estimates

Hiten Shah wrote an article titled “My nightmares with engineering estimates” where he blames everything on estimates. Now I get that he is using a little hyperbole to gather interest on his next post which is going to reveal The One True And Righteous Way™ but I need to get a few things off my chest.

Before we get into this I do speak from experience. I’ve been building software for 30 years in all sorts of roles and team sizes. I’ve been thinking about this estimating stuff for a long time as well. See my 2008 post on estimating.

No Estimates

Hiten describes how they got started with KISSmetrics without creating estimates and how they got to a point where it was going to take 90 days to make the system performant for customer demand.

We were screwed. All because of no estimates.

I have to call BS here. They got to this point because they traded speed to market for quality (by his own admission) and didn’t think about the non-functional requirements (such as performance). Not many of us have the problem of too many customers. Sounds like a great problem to have.

Had we estimated during our 30-day buildout instead of after, things could have turned out really differently. The business could have grown faster and been bigger today.

I have a hard time believing this as well. Having estimates doesn’t mean you have a high quality product that meets all the customer’s needs. I’ve worked on many systems over the years that were estimated at the start of the project and it still didn’t meet the overall goal of satisfying the customers or stakeholders.

Hiten lists 3 no estimates pitfalls:

  • No Tradeoffs Made
  • Too Much Time Communicating
  • Tasks Aren’t Broken Up

Part of product management’s job is to evaluate the opportunity vs. the cost which means making trade offs. Estimates are one input into that decision making process. I would claim it is a second level factor not the primary driver as he appears to be asserting.

Comments closed

Product Characteristics

Every now and then I get a product where there was limited effort put in to translating the description or instructions. This is the latest one:

This product is a new science and technology product and made with high and new science and technology. It can illuminate only placing it in rhythm.

No need any power, no environmental pollution. Low noise and health. Comparing with common torch it can be several times on lift.

Constantly using the health torch it can benefit to your palm, arm and shoulder stretching and blood circulation, so as to let your hands relax and brian clever hand and brain coordinate and promote your brain memory and health composition.

Comments closed

Back end vs. Front end

A co-worker sent me this today. So representative of many systems.


Comments closed

Electric Vehicles and Infinite Torque

I’ve seen/heard a couple of references to electric vehicles having “infinite torque” and something seems to be lost in translation. What they are referring to is that electric motors have “peak torque” available at 0 RPM. Essentially their torque curve is flat unlike internal combustion engines.


Image courtesy of

Note that the torque curve doesn’t stay flat forever, eventually the limitations of physics prevent that.

Below is a comparison of a Tesla Roadster and Chevy Camero from


The following graph shows the torque each car’s rear wheels experience during an all-out run from a stop. The dips in the Camaro’s torque are the shifts between gears, which happen quite quickly and are among the smoothest you’ll see. Note that the Tesla has no interruptions. Between 0 and 55 mph, the Tesla is the clear winner, even though by 40 mph, the Tesla’s AC motor output begins diminishing.

Comments closed

Who, what, when, why, how

I’ve written in a number of places before, but as time marches on previous locations make less sense than they use to. This is my new spot.

  • Who: I’m Wayne.
  • What: I run software based businesses.
  • When: I started my professional journey in 1989 when I went full time in my own software contracting/consulting company.
  • Why: I like solving problems and helping people.
  • How: I am a pragmatist. I have an affinity towards agile/lean

There of course is more to a person than what they do professionally

  • I’m happily married with 2 great kids
  • I enjoy reading science fiction, riding motorcycles and brewing beer (not all at the same time).
  • I’ve traveled more than the average bear, but less than some. I plan on traveling more.
Comments closed