News

Over the years of delivering working software we have carefully carved a pathway to how we do our best work. Many of these habits and workflows resemble agile methodologies very closely, while others were more ideas that evolved from traditional agile approaches. Like any successful project, our approach is also expected to grow and iterate over time. The following is a representation of how we are currently working together to build software products.

We believe the best solutions come from working together. Collaboration is at the heart of everything we do, including striving for full team discovery. We value diverse perspectives and open communication to achieve the best outcomes, and by working together to plan our work, we can deliver optimal solutions through shared understanding and clarity.

At Engage, a handful of us get together once a week as a book club to read and discuss selected titles over the course of a couple months. We recently read Software Teaming by Woody Zuill and Kevin Meadows and shared our review and a few take-aways at one of our weekly Lunch & Learn sessions. Here is a transcript (lightly edited for readability) of the presentation.

Mercenaries build whatever they’re told to build. They take orders. Their job starts and ends with executing tasks. They may be competent, but they’re not invested in the problem space or the outcome. Missionaries, on the other hand, are passionate about what they’re building. They deeply believe in the problem they’re solving. They own the outcome, not just the output.

Software teams typically include people with a wide variety of skills, including management, software architecture, visual design, UX design, data design, and business insights. A common “money-saving” approach is to have someone with management skills work closely with customers closest to the business goals in order to decide what should be done next, and then that management person will turn those ideas into tasks that the engineers and designers implement. However, the best teams understand that using designers and engineers only for implementation is a waste of their talents, and instead create a virtuous cycle of collaboration by bringing everyone to the table.

How can you know how long a new initiative to build a custom software product will take? What’s a reasonable amount to plan to pay to get started turning your vision into technically excellent software that can go live and start producing value? Once an estimate of the effort has been created, how close should you expect the true cost to be?