How much technical detail is too much when talking to non-technical managers?

Question

I have a boss that is not very technical. He can write some basic SQL, speak some dev lingo, but all in all not a pro dev. I get into trouble often, by giving him a lot of detail and asking him to make a decision as to which direction he wants to go.

For example, recently he asked for a bunch of changes to go into a product. Then took 80% of the changes away saying he is not ready to release these yet.

But then, I speak to our lead developer and he tells me to just push it all. This way we avoid having to manually merge code that we do want pushed vs code we do not want pushed (by push I mean move from dev to QA, forward merge).

So, the lesson is...do what's easy. Don't tell the boss that you are pushing up all the stuff. This doesn't seem ethical to me, but this is what the solution turned out to be.

So, where do I draw the line? Do you feel that hiding details is unethical or just a normal job function of a developer? I ask only highly experienced developers answer this question (10+ years). I know there's skilled guys with less experience, but I want experience to speak in this case, not just skills.

Answer 1

Not telling your boss about changes you have pushed, that they specifically asked to be removed doesn't seem like a solution at all. It seems insubordinate at best. So you have to be careful in how you explain to your manager why that decision was made, and how it does introduce undo risk into the product.

The trick of course is avoiding that situation in the first place.

I think the root of your problem might rest in how you are presenting your problem to your boss. At the crux of it is that is sounds like you are asking a non-technical person to make a technical decision. That seems folly. I am going to assume that this non-technical person has a better grasp of the business context of the problem. If so, then that is what you need to focus on. Help your manager understand how each of your proposed solutions addresses the underlying business problem. Help them understand the time it will take to implement the solution, what that will mean to the schedule, and the benefits it might mean down the road.

Most often the solutions a developer needs to present are along the following vectors:

1. Here is a quick solution, that addresses the problem on its surface, will allow us to maintain our schedule, but will probably need to be completely reworked down the road.

2. Here is a solution that will take longer to implement, will mean we have to delay a launch, but will provide a better foundation for the product technically going forward.

If this is applicable in this situation, break it down for them in those ways. Make sure they understand the business and technical risks associated with the technically weaker solution as well. The technical details are actually somewhat irrelevant unless you make them relevant by making them the focus of your presentation to them. Instead, try to present your solutions through the lens of the business.

Finally, if the technical details are essential, then involve the lead developer in your presentation to the manager. Come in prepared and united. Practice what it is you want to say so that you are clear and concise. Bring in a 3-10 slide powerpoint presentation to help visualize your solution. Don't get bogged down in the weeds of presenting code, keep it high level, but sufficiently detailed to keep them informed. Make your recommendation and the rational behind it clear.

Answer 2

In order to make good decisions, managers primarily need to know two things from you: schedule and risk. For example, if he wants to remove 80% of a feature set at the last minute, tell him how much extra time it will take to remove, and your estimate of how likely that is to break other things, requiring unpredictable debugging effort. Tell him those two things whether he asks or not, and don't give him any technical details he doesn't specifically ask for. People often erroneously assume taking out a feature requires zero effort. If you correct that assumption and he still decides to proceed, that's his decision to make.

Also, if this sort of thing happens a lot, then reevaluate your architecture and version control branching model to make that style of configuration management easier. That means developing features independently in their own branch and/or module so they are easier to add and remove as needed.

Answer 3

IME, the key here is to have enough mature team members that can reach consensus so that it isn't just for one person to decide whether or not some group of features go into a release or not. Course it isn't easy to get a team to have the experience and say, "Hey, this isn't going to happen. Sorry." or "Hey, we could get more done than we thought, what else would you like?"

While hiding detail is one perspective, another is the question of time management and optimizing communication. For example, would you detail all the troubleshooting ideas used in fixing a bug over and over again if you asked someone for help? Do you disclose all food sensitivities and allergies before eating at every restaurant? Wouldn't these also be cases of lying by omission? Just pointing out the question of how far would you take this professionally and personally.

The lesson may be do what makes sense. If it would take a lot of time to undo the changes and then redo them then it may be better to just leave things where they are now.

Answer 4

I suppose your manager is accountable for your deliveries to the customer / upper management / other parts of the organization. If a feature is pushed in that your manager explicitly requested not to be included, and your customer discovers that it malfunctions, that puts your manager in a very uncomfortable situation. Sounds like you need to sort out the decision making in your team. Perhaps your manager and your lead developer can clear the air and come up with a better process.

Answer 5

In my experience you have to decided this on a project by project basis. But really it should always comes down to its a business decision based on value vs cost. It hard sometimes for developers to think this way and we get ourselves in trouble by thinking in terms of "It's not going to hurt anyone and will just be more work for me down the road." Usually what I do in these types of situations is basically try and lay it out in terms that the business user understand, not hiding anything but give them a level of detail so they can make an effective decision. In your specific example you could use something like,

These 10 features are ready to be deployed and by not releasing 8 of them it will cause x number of hours/days of delay for the current release and y number of hours/day extra work for the next release. Also if we do not push feature #2 then feature #9 which you do want will not work completely or will be incomplete.

Then lay out the options

If we do push all 10 features then we can disable #1-5 and only user x will have access to #6-8 so we can communicate with them. Or what ever the mitigation is for releasing the features before the business is ready for them.

I always tell developers when they talk with business minded folks that most of the time its not really that you need to speak a different "business" language to them it just that you have to be comfortable with the level of detail that you give them. As devs we tend to go into the weeds, laying out all the options because thats how we solve things. When you talk with business users you have to be comfortable communicating with them the one pager, the highlights, the facts that help them make a good business decision.

Answer 6

Stop trying to verbalize technical details. Let the boss know how much time it will take and offer to come up with a quick list of everything involved. Leave the lengthy discussions if you need to clarify a particular concept or theory. Those who don't get it will tune you out.

You can only hold so much in your head unless you're able to have some sort of reference. Master chess players perform no better than novices at memorizing chess pieces that have been randomly placed on a board. If they are they are in line with a typical chess match, they do much better.

Answer 7

Whose job is it to decide what features go into the release? In my experience, it is the development manager's. If you are squeezing in extra stuff that he doesn't know about because it's useful, that's great. I don't know that I would go so far as to push things he explicitly said not to push though, because that could come back to bite you.

Ultimately, it sucks if you spent time on something and aren't able to include it currently, but maybe the reason it's not supposed to be pushed is because you don't have sufficient QA resources to test it adequately. I'd rather delay a feature to a later release than have it out there without being properly tested.

I used to have a manager that didn't want to know the technical details of anything. If I described a problem I was having with a feature, the more I would describe it, the higher his blood pressure would go (it was almost a visible change). So, maybe you should just not provide too many technical details. See if that helps.

Answer 8

woah there!

this could potentially byte you in the ass one day...

Do you not have a release/ change log?

Edit:

In essence what I was trying to say, is that by documenting the releases, planned changes, bug fixes. It can be clearly communicated to your boss, this can INCLUDE the technical details, but also the high level description of the changes (proposed or otherwise).

This resolves the issue of "oh, at what level of detail should I communicate to my boss?"