Skip to content


Time Spent is Our Product: How We Optimize for Effectiveness

As a full-service IoT engineering firm, our revenue comes from customers paying us directly for time spent working on their problems.

This type of business model yields a different set of constraints and a different set of criteria that you need to optimize for compared to what you’d likely encounter at a “product” company. At a product company, time spent building the product does not correlate linearly with revenue.  

Additionally, at a product company, the things that you’re optimizing for will remain relatively fixed (i.e. software “quality,” ensuring team members are meeting the expectations of their role, and meeting customer needs). At a consulting company, meanwhile, these can vary drastically from project to project.  

When teaching members of our teams to navigate the consulting environment (which can be prone to high levels of churn and burnout), I point to the fact that though many constraints change from project to project, the most critical thing to remember is that time is the most important variable to consider in all decisions.

Defining Time Management in Technology Consulting

On the surface, when your boss tells you that time is your most critical resource, you may gravitate toward time management strategies such as the Pomodoro Technique®, the Getting Things Done (GTD)® method, or the Eisenhower Matrix

Time management strategies are designed to ensure you’re making progress toward well-defined goals, given a fixed amount of time.  For example, “I need to accomplish X, Y, Z over the next week.”  These techniques can be effective, but only within the constraints they are put under.

As an engineer, data scientist, or designer, it’s possible to get a list of tasks from your project manager and apply some time management techniques toward accomplishing these things.  All other things equal, someone who does this will outperform someone who doesn’t.

However, there are other outside factors that can improve an individual’s effectiveness by a much greater degree than any time management framework can.

Most frameworks approach time management like budgeting. They’ll say something like,

“I need to accomplish 10 tasks over the timeframe of the upcoming week, given that I have to sleep, and fulfill my standard familial duties.” 

Similarly, budgeting systems often provide methods for achieving some statement like,

“I need to save $10,000 over the next year, given I have an annual income of $90,000 and my mortgage payment is $3,000/month.” 

Of course, if you follow a strict budget, you will be able to achieve this goal.  However, if you drastically shift the problem constraints by getting a new job that pays $100,000/year, the goal almost achieves itself. 

The lesson here is: Budgeting of a resource will give you incremental efficiency gains, but taking actions that dramatically add to the availability of a resource, or dramatically reduce your dependence on it, will have a much greater impact.

What “Time Management” Means at Very

At a policy/culture level, it’s not interesting to look at time management frameworks and insist that people use a particular one, or use them at all.  Instead, it’s interesting to investigate how we can think about problems such that we are making dramatic changes to the consumption of time (since unfortunately, unlike with money, it’s impossible to make more time).  

Technical team members in the consulting industry are under immense pressure to predictably deliver value to clients who are paying large sums of money for their expertise.   This means, as mentioned, that our team has to be ever-vigilant when it comes to how they are spending their most precious resource: time.  

At Very, we’re constantly asking questions as individuals and teams about ways we can optimize our systems and processes to deliver the best possible results in the time available. These are questions like:

  • Is there a task in my development workflow that repeatedly costs the client time? 
  • Is it possible to spend some extra time now in order to save large amounts of time in aggregate in the future?  
  • What is the last moment of responsibility for making a decision? 
  • At this exact moment, am I taking the fastest path to a solution for the client?  
  • Will a time-saving shortcut now cost me time in the future? If so, how much, and should I still take it? 
  • Are the tools we’re using, and the way we’re using them, allowing us to do our best work in the time given? The flexibility of a system is important, and the ultimate “quality” metric.

How We Work This Into Our Process

We de-risk every project from the beginning.  We begin every project with a Technical Design Sprint where we work to define business needs, give context to end-users, and better understand the solution we’re bringing to market.  By the end of the sprint, we have developed a phased product roadmap that defines the fastest path to a minimum viable product (MVP). Taking this additional time to do research up-front prevents time and resource loss down the line at more critical intervals.  

We practice Agile and Lean development methodologies.  Our highest priority is to deliver valuable, working software in a predictable way, which is why we strictly adhere to an Agile software development approach. Lean software development, meanwhile, emphasizes optimizing efficiency and minimizing waste in the development of software. 

We self-evaluate throughout the IoT development process. We involve QA from the beginning of every project and conduct frequent testing to ensure that what we’re building will work for our clients in the real world. We also hold retrospective meetings throughout a project, with one larger meeting at the end, to talk about what went well, what didn’t, and why. Each meeting has outputs, or actions we take to improve or optimize our tools and processes. 

We work remotely. We’ve been a remote-first company since day one, and for the last several years we’ve been remote only. Being remote-only allows us to hire the best people for the job, no matter where they live, meaning that every employee at Very can directly connect the work they do with the success of our clients and company. With a fully distributed team, we’re also able to ensure that every employee has a distraction-free space to do focused engineering work and can maintain a healthy work-life balance. 

We obsess over communication — with clients, and with each other.  Miscommunication can derail a project at almost any stage. In addition to creating a tightly defined meeting cadence for our clients, we also take steps to ensure every team member can access the information they need to do their jobs — whether that’s via video conferencing or chat, through religiously documenting our processes, or by creating systems that facilitate understanding between engineers from different disciplines (like hardware and firmware).   

We practice holacracy.  Nothing stops a project from moving forward like needless bureaucracy and red tape. By practicing holacracy at Very, we’re able to encourage transparency between team members regardless of “rank” and help teammates remove potential blockers keeping them from accomplishing their tasks. 

Want to Work with Us? 

Time and time again, when we ask our clients what stands out most about our work, they say it’s our process and the way we optimize for effectiveness. 

If you’re looking for a development team that works tirelessly to make every minute on your project count, we’re here to talk. Reach out today to tell us more about your project. 

IoT insights delivered to your inbox