Project Politics or How to Pass your Proposal through Management

Gabriel — Tue, 26 Mar 2019 03:46:25 +0000

It happened again, the frontend test build failed after 40 minutes running. A unit test failed. Funny enough, only 10 of those 40 minutes were consumed by the unit tests themselves, the rest were just cloning, npm installing and doing the same setup operations done by countless other builds before.

If anybody had had a spare minute - and the required motivation - we would have known that Docker is the perfect tool for this (here is an excellent article from Alex Barashkov).

After two years, this build represents to me everything that is wrong with my project: there is no time to innovate. The build is only one of the pet peeves that we developers have to face. Sometimes we would come up with proposals for management, and the answers would be like:

Yeah but, how do I sell that time to the client? It is not development.
There's no capacity. The go-live is next month and we have 200 defects! #trueStory
Hmmm... yeah.. it would be nice but.. - followed by an awkward silence

Tough management. To make things even more complicated, there are many layers of management and divisions in the organization with even more management. Getting something done quickly turns into politics. So, how do you get something done in politics when you are a rookie?

1. Define the Problem

This sounds obvious, but sometimes I see people saying: "yeah, let's adopt Docker!" and when you ask them why they mumble something like: "well, you know, it's better". Not enough. Your problem has to:

Be other people's problem
Be visible to management (it has an impact on the velocity)
Have a clear cause and consequences (e.g. backend code keeps breaking the page)

2. Define a solution

What do we need - Infrastructure / Resources / Technologies?
What improvements should we expect?
How are we going to do it and how much time will it take?

3. Build a small dev team with people interested

This is about making other developers own your proposal as well and joining forces to show management that this is other people's problem too. It also helps you explain it and benefit from other dev's points of view/experience.

4. Build an MVP

That's it, you have the idea, you have the people, now build it. Make it small (you just need to prove that it is doable) in your local machine, and when you have it ready it is time to knock on management's door.

5. Get the votes

In Politics, you don't go to the stand without having the votes first. You do all the talking and convincing and cut the deals before the vote has even been called for. Well, this is the same.

Do not set up a meeting with everybody without knowing the outcome first

The outcome is decided by the people who have the steering wheel in the project (typically architects and project managers - but not all of them).

Have some informal chat with them, maybe over Slack or while getting a coffee to get an idea of what the decision would be (do they agree it is a problem? Are they excited about the MVP?). Then set up a meeting with everybody else.

5. Showtime

Summon all the team to a single meeting. In the invitation email, clearly, outline the agenda, provide resources (E.g. Sharepoint page) and briefly talk about what is this about.

I usually prepare a high level, non-technical presentation of about 15-20 minutes. Then I allocate another 15-20 minutes for questions. Questions are where you want to go low level technically and prove that you know your stuff without risk of people dozing off.

I usually run like them this:

Hello everybody, thanks for joining, this what I am going to show you (what is the problem the DEV team has, how is it impacting our velocity, what solution have we come up with, and what do we need from you next)
The problem
How does it impact our velocity
Questions?
The solution
Demo
Questions?
What do we need from you
Decision time

-> Yes? get commitments (who is going to do what/when?)
-> No? ¯\_(ツ)_/¯ && exit(RAGE_QUIT)

Finally, wrap it up: this is what we saw, this is what we are going to do next. Thanks

Also, it is likely that people will still have questions or need some internal discussions around the proposal. So be prepared to have a follow-up session.

Bottom line

Many people rush into asking management first and then work on their proposals. In a project where time is a clear constraint (and I am yet to work in a project where it is not), this is not how things work. Unfortunately, many decision-makers are not there involved in day-to-day development. Simply put, they don't have your problems. Or, perhaps, they may not see how does your solution fit in because they don't know about the technology. However, sometimes the problem is your solution and some quick prototyping could have revealed the flaws.

On top of that, when you have not yet built your status as an experienced software engineer (you are a rookie), they might just not trust in your ability to deliver it.

And this is the real problem. In a high-pressure project, nobody is going to let you use your working time on that. So (and follow me here) how do you build something, to prove to them that you need the time to build it, without having the time? Here are some options:

You build your small team and let them help you whenever they are free.
You go small, really small on your MVP

And, no, you should not be using your free time for this. Protect your free time!

Thank you for reading my post. Looking forward to reading your comments!

DEV-only tooling for Web Applications

Gabriel — Tue, 22 Jan 2019 11:44:48 +0000

Hi All,

At work, I am working on a quite complex web application that presents the user with a flow with a series of pages that gather user data. If the user wants to reach a page, she has to go through all the flow to reach it. Sometimes this can mean as much as 10 pages, with 4-10 seconds of saving time with the backend between pages.

We, developers, used to have to go through the same process every time we wanted to make a change to one of these pages. So you can imagine the pain of revisiting a page on the flow multiple times.

I came up with a tool that allows you to refresh the page in place, by copying the user data in sessionStorage and recreating the flow up to the very step where you left it. This happens almost instantly and saves us many hours of combined time.

My problem is that the tool is hard to set up and this makes other devs reluctant to use it. I have in a separate branch, but it requires tweaking files that get constantly modified, causing merge conflicts every time we want to merge it with our actual code.

I have thought of using webpack and a variable replaced at compilation time based on environment, so we can have it available only in our locals. The problem is that the code would need to be there along with the Production code, even if deactivated.

I struggle to find a better way to make it easier to maintain and use. Does anybody have a strong argument against not merging dev-only code along with production code? What could go wrong? Are there any alternatives to the branch-based approach?

Thank you.

DEV Community: Gabriel