You have 0 further articles remaining this month. Join for free to read unlimited articles.


Have you ever started a project only to realize half-way in that it is much more complicated than what you originally thought? And that it would take twice as long? And that it would need collaboration from 3 different teams because it touches their codebase as well? You’re not alone!

June 27-29, 2023 Conference
graphic element

Join us at the Barbican in London this June

With a conference for every level of engineering leadership, find a community that will help you reach your career goals.

Software engineers across various organizations have run into this same issue - but what’s the solution? Is it Big Design Up Front? Is it to be “agile” and let these things happen? OR ....... is there a better way, by which you can do *some* upfront work and save yourself a lot of thrash and a future headache. This process is usually called a spike, wherein the engineer(s) leading a project dive deep into figuring out the unknowns of a project before it begins. In this talk, I’ll go over what a spike is, how to successfully spike a project, and lessons that I’ve learned from leading several technically complex projects, across 3 different companies, and various different teams.

Key Takeaways:

- How to evaluate whether you need a spike or not.

- How to come up with the right assumptions you could validate/invalidate before writing the tech spec.

- How to find the technical scope of a project (Teams, Services, Key Stakeholders) that’d need to be involved.