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:

1. Yeah but, how do I sell that time to the client? It is not development.
2. There's no capacity. The go-live is next month and we have 200 defects! #trueStory
3. 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:

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

2. Define a solution

1. What do we need - Infrastructure / Resources / Technologies?
2. What improvements should we expect?
3. 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:

1. 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)
2. The problem
3. How does it impact our velocity
4. Questions?
5. The solution
6. Demo
7. Questions?
8. What do we need from you
9. 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:

1. You build your small team and let them help you whenever they are free.
2. 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!