My Boss Doesn’t Allow Me to …
Last week I was speaker at a large conference in Germany. Although I mainly covered technical topics concerning software development, the most asked questions weren’t around programming. Instead, people complained that their bosses prevent innovation by not allowing them to invest time and money in promising new technologies or methods. Here are some examples of statements I heard:
- "What you tell us about agile methods sounds great but my bosses force me to write endless specifications and super-detailed project plans upfront. I know that this is a waste of time, money and paper but they will never stop to demand that."
- "The tools for automated unit testing look great, but before we can use them we need to spend at least some time in refactoring old code. It is frustrating, our management doesn’t give us any budget for that."
- "We would love to profit from the agility of the cloud, but our management babble something about policy and security of Facebook. They don’t understand how mature and professional B2B cloud offerings are and so we continue to wait for weeks if we need e.g. a new development server."
I could continue with similar questions. People asked me how I would deal with such situations. Here is my most important advice:
Stop complaining, start making the problem transparent and measurable instead.
The Managers’ Problem
Try to step into the shoes of your manager for a second. Many of them are no domain experts. Maybe they had profound domain expertise years ago, but management tasks do not allow them to keep up to date with the details of technology.
Additionally, they get asked for budget every single day. I don’t know a single company who does not struggle with limited resources in terms of personnel, time, and money. Managers have to come up with a system of triage that allows them to quickly pick and choose the most important projects.
With that said, do we think our bosses deny their approval to e.g. upgrading to the latest and greatest development tools just because they are ignorant?
Or could it be that it is our fault because we did not make the benefit of our proposal clear and transparent enough?
Be Self-Critical
Next time when you want to propose a change in your organization, pause for a second and think about whether you already have a razor-sharp business case that supports your idea. Here are some questions that you can use for self-evaluation:
- Can you comprehensibly describe (e.g. with text, illustrations, etc.) the underlying problem as well as your solution?
If you are looking for inspiration concerning illustrating your point using pictures, take a look at The Back of the Napkin by Dan Roam.
- Do you have quantitative facts (e.g. costs, wasted working hours, declined ratings in customer satisfaction surveys, etc.) that support your point?
- Do you have qualitative data (e.g. customer interview, case study) that illustrate the problem?
- Do you have serious estimations about the potential benefits (e.g. rise of revenue, lower costs, faster turnaround time, etc.) of your project?
- Can you provide an honest risk assessment?
Before you start fighting for the innovation project that you are passionate about, ask yourself if you would approve the budget if you had a management role.
My tip: Ask a colleague to assist you and take the role of a project opponent. What arguments would you come up with to stop the project?
“You Can’t Manage What You Can’t Measure” – Wrong!
Have you ever heard the quote “you can’t manage what you can’t measure”? Most people use it entirely wrong. The quote goes back to W. Edwards Deming. In contrast to what most people think, Deming did not say that you should only manage based on measurable facts. On the contrary, he stated that ignoring “figures that are unknown or unknowable” (source) is one of the seven deadly diseases of management.
A convincing project proposal combines soft AND hard facts. However, in my experience we are good story tellers (=soft facts) but we often try to avoid the hard work of gathering numbers.
Two Examples
- You want to have a budget for refactoring existing code and establishing automated unit tests in your project? Gather detailed and exact data about customer trouble tickets including categorization, time to solution, effort, etc. Do a root cause analysis for the most costly cases and document why your approach would have helped (e.g. less trouble tickets, faster response time, reduced number of trouble tickets, spend more time with new projects instead of support).
If you still manage your support in your inbox or Excel sheets, I encourage you to use a professional ticketing software like Zendesk instead.
- You want to use cloud computing at least for testing and development? Document the time that you spend waiting for or struggling with e.g. development environments. Use case studies to describe situation where projects were delivered late because of missing servers (ideally you have concrete costs like contractual penalties that your company had to pay). Track the time used to setup, maintain, and troubleshoot systems. How would e.g. PaaS remove such costs?
Costs of service departments are mainly driven by labor costs. Whenever you argue that your project would help saving money, you have to know how your teams spends time today. How could your project change that? With SaaS offerings like time cockpit you can even get a professional time tracking solution for a limited amount of time without having to pay for expensive licenses upfront.
comments powered by