Funability, Part 3 – Maximizing Productivity
Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:
Part 1 – What and Why
Part 2 – Leverage Your Leadership Roles
Part 4 – Processes Can Be Fun
Part 5 – A Layered Approach To Quality
In this third part of our series, we are covering the importance of creating environments that maximize the productivity of your engineers. Here we are specifically talking about aspects of our culture and environment that are separate from the more familiar developer productivity strategies related to software design/construction and agile methods.
Of all the strategies we are discussing in this blog series, these are strategies we didn’t have in mind before building Nebraska Global and Don’t Panic Labs. It reminds us that we never really “arrive” as an efficient, fun, and productive software development culture. There are always things to learn and try, and it is important to always be reflecting, evaluating, and implementing new strategies to improve the level of funability in our organization.
Protecting Schedules
It’s easy to fall into the trap of thinking that all time is created equal. Two 30-minute sessions produce the same quality of output as one 60-minute session, right?
Nope.
One of the hard lessons we learned in our early days was the value of keeping schedules free so engineers could have long interrupted sessions where they could just work. The concept of “unmuddying” schedules wasn’t even on our radars.
In the early days, we would schedule meetings willy-nilly. If someone thought a team should gather to discuss a particular topic, we put it on the calendar. But these meetings didn’t occur just once a day; they became frequent, a bad habit.
As you can imagine, our days became a mess very quickly. We had the early-company urgency that kept fires lit under us and we were okay with it. Until we recognized the cost.
One day we woke to the realization that our engineers were left with only small slices of time to work on their projects. Their day was relentlessly divvyed up amongst all of their various meetings. It had become apparent this was not sustainable. We were robbing our engineers of solid blocks of time where they could knuckle-down and be productive.
We used to make excuses, telling ourselves we were good multi-taskers and could just deal with it. But that just wasn’t the case. Our engineers would find themselves returning from yet another meeting and spending about 20 minutes just getting back to where they left off. The constant interruptions were hurting our efficiency. The cost was just too great.
So we stepped back and analyzed the situation. We found that if you give your engineers 4+ hours of uninterrupted blocks of time to focus, they will be more productive, they will enjoy what they’re doing more, and the team will have better software to show for it.
To make sure we don’t fall back into our former meeting-heavy mindset, we operate with the basic plan that we only allow meetings in the mornings. If some emergency comes up and we need to get together, we’ll make time for it (but it had better be a BIG emergency). In the end, we must be strict in protecting the time of our engineers.
As a graphical before-and-after illustration, below are two calendars. The one on the left belongs to Doug. This is typical of what our engineers used to see before we changed our approach to meetings. As you can see, there’s very little time for real work. It’s a productivity disaster. The calendar on the right is a typical calendar today. Sure, there are a couple irregularly scheduled meetings. But for the most part, most of the day is in the clear.
For some additional thoughts on scheduling, we recommend Paul Graham’s blog post Maker’s Schedule, Manager’s Schedule.
We understand that making a change of this type requires a lot of company and culture buy-in. This may not be something you can just “flip a switch” and make happen right away. It’s a real adjustment. But how we run our schedules at Don’t Panic Labs is proof that it works and we are now strong advocates for it.
Local Resources
Another approach to software development that we hadn’t considered in the past was making sure the engineers could run every aspect of their projects on their machines.
Oftentimes there are additional resources that reside in other locations. Perhaps this is a service on another server or a big SQL database box. But if the engineers are spending their time connecting with many “outside” resources, that is time not well spent and can quickly lead to frustration (the opposite of fun).
What if the entire application stack was available on the engineers’ local machines?
This is what we asked ourselves, and then sought the answer by trying it out. In short, it made a world of difference.
For one, your engineers can more quickly develop their projects without spending a bunch of extra time configuring the required remote components. Whether it’s a mock service or a local database, having everything local makes it a lot faster to get up and going.
This approach also creates an environment where engineers aren’t vying for a limited number of resources or having to work around configuration changes/differences on the shared resources. For example, if a centralized SQL server is used for the development team, one developer’s changes that require a database modification will be difficult to manage on a shared server without coordination with other developers to ensure they will be able to test as well. This extra “configuration management” is burdensome and frustrating as a developer.
Achieving this ability to develop and test locally (including database resources) may sound hard but we have been able to achieve this across all of our product platforms in Nebraska Global. It does take some advance planning and adherence to this ideal (including finding the right tools to make it smoother), and we have found that it actually drives some design decisions about our applications that enable/preserve this ability. It also requires the ability to do iterative database design with a solid, script-based, configuration management process for database design and deployment.
As almost a bonus, having as many of the project’s resources locally available also gives engineers the flexibility to work wherever they want. They’re no longer tied to our internal network. They can take their entire project with them on their notebooks and work at home, at another off-site location, or on our deck. This is funability at its finest.
Is that it?
We’ve learned quite a bit about making opportunities for developers and engineers to maximize their productivity. But we’re still not done. We still have more to cover.
In our next post, we’ll show how design and layered quality processes contribute to funability.
This post was originally published on the Don’t Panic Labs blog.
