OVERVIEW
As discussed at the beginning of this year, we need to accelerate our progress in terms of craftsmanship and mastery. Using DevOps fully (which requires involving everyone on the team) is on that road and is likely the point where we can have a wider ROI across the board, as it is designed to help everything move faster and therefore give us more time to then improve on other, more specific, parts.
IMPROVING THROUGH DEVOPS
We have several different patterns of inefficiency problems that waste our time, while time is our most valuable resource.
We know there is some room for improvement in terms of processes, tools, and practices that help us take an idea to production in a reliable, effective and efficient way. We also could use part of that improvement opportunity to level up our skills in automation, which would help us grow as individuals and company. The meta problem, however, is that these issues in some cases have orthogonal solutions: the obvious solution for one could make the other worse, which is one of the reasons we should be careful before committing to a technology or process without understanding how it might fit the bigger picture.
To have a better frame of reference, here are some of the problems and inefficiencies we have:
- Difficult project onboarding, causing friction when people want to setup/start contributing to a project, wasting time and creating a negative incentive to collaboration;
- Low test coverage, leading to find bugs late in the process and making them harder to fix while reducing the maintainability of the projects. Lack of test coverage is one form of technical debt;
- Manual server operations which make operations more dependent on the specific individuals who setup the system previously and are naturally error prone, reducing the team ability to operate the systems autonomously and reliably;
- Limited team autonomy, where only a small subset of the team has the knowledge needed to operate a system in their head, leading to high “bus factor” and slower response time when one of those persons is not around;
- Server costs are currently at ~$650 between Heroku, DO and AWS, which isn’t a crazy amount, but looking at what we have currently running there’s clearly room to optimize a bit here;
- Friction in deployment which translates on us using less staging for validation and testing than ideal, leading to more issues found later in the process and unplanned delays in getting into production things that ultimately are already done.
THE RISKS OF FIXING THE WRONG PROBLEMS
Pursuit of financial efficiency in operations at the cost of engineering time
When looking into this, we also need to keep in mind that engineering time, by default, is more valuable than cash. As engineers, we have an urge to build, but our time is a very limited resource, and we should focus it entirely on the parts of our products and projects that have the highest impact and make us stand out or learn something new.
As so, we should have a bias against developing or maintaining tooling and infrastructure, unless those are part of our unique value proposition, as they are stealing time directly from our mission to build and iterate products. Obviously spending the time to learn can and should be dissociated from maintenance, so that’s always welcome.
To evaluate if it’s worth spending the engineering time to save money, we should consider not only the cost in time of the team (probably multiply it by 2-4 to account for unexpected maintenance) but also the cost of context switching/reduced focus. Another qualitative way to help make this decision is to ask ourselves where our time will have the most impact on the long-term: spending 4h maintaining infrastructure or spending those pushing Qold, Unplugg or other Investment Time endeavors forward.
This doesn’t mean that we have an unlimited capacity to spend money, but instead that we should invest it to move forward faster. On the other hand, if at any point costs for given service start to become meaningful financially, meta team will review those to ensure they are healthy and wise.
Pursuit of control at the cost of easy of use
There is a classic discussion between if one should optimize for convention (which tends to be faster to use) or configuration (which tends to give more control). As any balance, it’s hard to be prescriptive about where the sweet spot is for us in all problems, but culturally we should find ways to be more coherent about it and have a common approach.
The best litmus test I can think of for this is that any solution should be easy enough to use that any member of the project team can use it autonomously. If that is ensured, we should pick the option that gives us more control.
In the light of DevOps, we could also frame this as: it is more important for the entire team to operate their own project with some restraints, than a subset of the team with full ability.
In the case of projects that support the company as a whole, like the ones we sometimes work on Investment Time, we should consider the team as the entire company and ensure that the majority of us is able to make basic maintenance on them.
WHAT IS DEVOPS AND HOW IT FITS
As usual in these matters, the definition is broad and subjective. The first important point is that DevOps doesn’t mean to configure and manage servers, which is a common misunderstanding. DevOps is a broad practice and philosophy that can be compared (and is heavily inspired) with Agile or Lean.
You could think of DevOps as the practices and feedback loops of Agile and Lean but with a wider scope, supporting the development process from the business input and ideas through the deployment and reliable operations of their implementation.
It arose organically by breaking the silos that contain Development and Operation teams, reducing the feedback loop time and bringing visibility to the whole process in a cohesive fashion. It relies heavily on automation and collaboration to amplify and accelerate feedback loops.
Beyond the explicit mention of business, development, and operations, on our work, we should see designers, developers, hardware engineers, and product management as members of the team and therefore involved in the full process. So everyone on the company can and should know what is DevOps and how they can improve our practices in this regard.
Operations work doesn’t disappear. Instead, it is integrated into the teams and focus on enabling the entire team to develop and operate the systems. At the same time, we should avoid seeing Ops as a role. Ops is a skill, and as any skill, some people are more into it than others, but everyone on a team should be able to wear the Ops hat once in a while at a basic level.
Currently, we already practice quite a few things which can be considered DevOps. However, there is a misconception of what this actually means which organically creates the silos which DevOps was designed to break. Without that habit of looking at business, development, and operations as a whole, we sometimes fall into the trap of over-optimising for a local maximum at the expense of the efficiency and effectiveness of the wider process.
We need therefore to be more mindful of DevOps as a lens through which we find improvement points on a project and help to guide technical and business decisions.
In another blog post, we will explain our DevOps definition of awesome - what we want to achieve in terms of DevOps and how we will do it.
We started the month with the need to compensate last month’s loss of 4k€, which put the goal for the month in 51k€. This number was updated when we finished our accounting from January, raising it higher than we first estimated: 52k€. With that new information, we had to update our goal for 56k€ of revenue and work harder to make sure that happened.
We had to make some compromises on the Investment Time side to make it possible, but our numbers tell us that the goal of 56k€ was successfully reached. We should be happy for the successful effort in making this happen.
On the sales side, we delivered 4 proposals for Multi-Layer Product (MLP) projects and 1 non-MLP. From those, we closed-won 1 new project, which for now will consist on a sprint of one week, with the possibility of continuation. We have been working on a few more prospects to fill our pipeline for March.
Relatively with the goals of the trimester, we still have one to reach: 1 Product Design Sprint.
For March, we need to work towards closing at least 1 or 2 new deals (depending on the size) to start during the month, with one of them ideally including a Product Design Sprint.
As a billable work goal, we need to achieve 53k€ to be above our currently estimated burn rate (which may change as we finish the accounting from February), and at the same time reach the goals we traced at the beginning of the trimester: 50k€/month.
So far we invoiced 119k€ this trimester, with a forecast of reaching 167k€ of the 150k€ goal we traced for the end of this period.
During Investment Time review there was some discussion around the launches that we had hoped to do during this month and didn’t happen, which is naturally not good. The issues this month appear to have been more in terms of planning and communication on Soundy side, while Slackernews got a few unexpected issues. As we also had to spend some IT working on consulting, that also made the month shorter.
The possible retrospective analysis here is that, each week, the teams that plan to launch something should spend at least a few minutes to review current state, understand if there are no blockers to launch, and define (or simply ensure it’s clear) the next steps and the responsible person for each on the road to launch.
On the other hand, Unplugg ended up being promoted on several online communities which also stole some of the focus to launch things on IT.
Soundy is ready to go and we launched it on Product Hunt last week (top 10 of the day :party:). Slackernews still has to fix a critical bug, which will allow us to release it for some family and friends so they can test-drive it for a few days (no more than a week) before a more public distribution takes place.
There were also some discussions in regards to productivity on Fridays, how can we measure it and if the changes of last few months have been taking effect. This is quite hard to measure, but generally, people seem to feel a bit more productive individually and in the team as a whole, even if no one seems strongly happy with the current state, so we should keep trying to improve.
A more tactical note is that meetings on Thursday seem to be effective to have more focused Fridays and the projects that spent a bit more time planning and making sure it’s easy to collaborate recently seem to have a positive impact on their productivity and progress.
For February we had 2 main goals:
- Validate the High-End Restaurants segment, by selling specifically to a strict group of restaurants instead of embracing the whole restaurant's segment;
- Have the new temperature sensor version ready for production.
We failed both goals, but there was more in this month than just goals, so here are the conclusions we made:
- We failed to validate the High-End Restaurants' segment because of several reasons and not just one. We took more time than we should plan it and our first two weekly retrospectives should have gone deeper on that subject. Despite the weak first 2 weeks, we did the last 2 at the pace that we aim and gained some terrain back;
- Regarding our hardware version, we were (and still are) dependent on an external partner to close this and, adding to the fact that sales are the top priority these days, our hardware improvements are moving slower than originally expected.
To keep up the pace and prevent weeks like the first 2 of February, we defined a mid-March goal of closing High-End Restaurants validation. So in mid-March (March 16 to be precise), we will evaluate this.
Hardware improvements will keep being our secondary goals and we hope to close it this month, as progress keeps being made.
In the end of January we established quite straightforward objectives for February:
- Optimize to close open leads, as sales cycles might take too long (we have 27 conversations ongoing); Find new sources of leads;
- Get 5 clients who use Unplugg two weeks in a row for energy forecasting.
February was a kind of deadline to evaluate if we should stick our focus on the energy market, or consider addressing a broader market, targeting new segments outside the energy field.
Considering the objectives established, February wasn't a brilliant month, but allowed us to realign our expectations and efforts:
- This objective was established to optimize our business development strategy in the short term. Due to the long sales cycles on B2B/Energy Markets, we focused our attention on current prospects (leads that had interacted with us at least once). We had 27 prospects during February and scheduled 20 calls. From these 20, 8 agreed to test our API and asked for all the instructions to proceed with the testing, but only 2 of these took action and tested the API. Unfortunately, not a single prospect use the API for more than a week. This is far from our objective but allowed us to identify the bottleneck of our sales funnel. There are two possible reasons for potential clients quit the sales funnel on this particular final stage:
- Our test site and documentation is complicated or confusing with too much information, which is the opposite of our value proposition - Automatic Forecasting easy to implement. When the client can’t clearly see the advantages of our API and how simple it is to ask for a key and test it, it means that our testing page doesn’t meet their expectations. Therefore we need to improve UX since the client enters our landing page until he finishes the subscription.
- Another potential problem is the transition from Business people to Developers. Most of the times we talk with business developers or heads of R&D departments. This transition process can be noisy and information can get lost or people just don’t have the time or the focus to explore the tools we are providing. To solve this problem, one of the things we will do is to recommend to potential leads involving from the beginning their technical or development teams to give context and show them how easy it is to implement/test our forecasting algorithm.
- We needed to find new sources of leads to feed our business pipeline with new prospects. As the interest in the energy field was vanishing (especially due to the lack of conversion on the last steps of the funnel) we turned to other potential sources of leads. We started by selecting developers and tech startup communities. To test this premise we launch a campaign in three main platforms: HackerNews, Reddit and Product Hunt. During this week we had over 3500 API calls (a vanity metric in my opinion) but 69 API key requests. This way we can contact all these potential clients that requested the API keys and learn what made them do it and create a standard user profile to understand who our target market is and how we can replicate our Business Development strategy. We are aware that there is the risk that all these API key requests are just people curious about our API, not for business use. Therefore, for March, we want to validate two specific market segments with very clear needs. One of our current hints is Small and Medium Businesses doing arbitrage of goods. During the Hacker News campaign, we were contacted by one of these companies that needed to optimize the shipment of goods according to sales forecasting. This is indeed a potential market with a very specific need to easily optimize their businesses to increase revenue. Our actions for the next month is to validate this need and market segment. Also during this month and mainly because of the campaigns we created, we have several hints to optimize the UX for our onboarding process.
- We could not fulfill this objective. The main reason for this failure, as stated before, was losing our prospects in the last steps of our funnel as previously explained. Right now we don’t have the needed information to tell which target segment is the most promising, but we have data to work on (69 new API keys are a very good amount of new leads).
Considering this, we are keeping as the main goal for March, have 5 users who use Unplugg two weeks in a row. To achieve this we established the following plan:
Business:- Follow-up all people who requested API Keys or subscribed newsletter;
- Follow-up with open leads em forecast for energy Validate through online distribution: a. Small medium Businesses doing arbitrage of goods; b. At least another segment (based on API key requests data).
- Make the system as a whole more reliable and easy to contribute to;
- Improve website UX to make pricing, subscription, use cases and testing more clear, right now we have lots of content not organized;
- Add confidence intervals to the forecasting results (the main technical feedback point we gathered from our campaign).
- 0/2 blog posts for WS Blog
- 1/2 blog posts for Behind the Scenes
- 1/1 slideshare
- 1 blog post for WS Blog;
- 1 blog post for Behind the Scenes;
- 1 slideshare;
- 1 blog post from a guest writer;
- Write 1 blog post for other blog or publication related to IoT, product management or web dev.
March will be a fun month to work on unplugg.
</div> MarketingOne of the goals of the marketing team is to share what happens inside our company to the outside.
This means sharing how we work, what skills our team has, what we learn developing our projects and with our mistakes, etc. So every time we write a blog post, go on social media, make a presentation or are just present at an event, we are marketing ourselves.
We started setting some goals related to "sharing", such as a number of blog posts per month or number of published slideshares, as an encouragement to have more people sharing their learnings and tips on different subjects.
These goals should be an encouragement and not a way to force someone to write or have a blog post just because. We want to share things with quality that truly represent us as a Company. Also during last month, we spent less time on Investment Time and a lot more working with our clients. This clearly shows how difficult it was to write and finish some of the blog posts we had in mind.
February goals:
We are also inviting guest writers to our blog at the same time we are trying to be a guest writer for other blogs.
In February we were also present at ShiftAPPens - the craziest hackathon in Portugal. As we mentioned before, we had some people from our team participating in the hackathon, but as sponsors, we also did some cool things during the event.  Our booth had the purpose of showing a bit more of our culture and also be the land of fun and relaxation seeing that people work *a lot* way too much during hackathons.
We also did our traditional quiz with some rather difficult questions about programming and design, but with a lot of participants (next time we have to do it on the main stage :b).
ShiftAPPens is a really important event for us not only because we can learn and do a lot of things as a team but also because we can share with everyone why we are a crazy family.
And what will happen in March?
Whit what we wrote previously, we decided to change the goals related to blog posts:
Next month we will also start implementing part of our inbound strategy by doing some changes in our twitter in order to start getting more leads from that channel.
### SEE YOU IN APRIL We would love to know your thoughts about our monthly reports. What else would you like us to cover? Or what can we share that would be helpful to you? Feel free to share any thoughts or questions on [twitter](https://twitter.com/whitesmithco)! Check out the posts of the past months: [February](https://www.whitesmith.co/blog/february-monthly-gathering/)
January part [1](https://www.whitesmith.co/blog/january-monthly-gathering-part-1/) & [2](https://www.whitesmith.co/blog/january-monthly-gathering-part-2/) November part [1](https://www.whitesmith.co/blog/november-monthly-gathering/) & [2](https://www.whitesmith.co/blog/november-monthly-gathering-2/)
The Non-Technical Founders survival guide
How to spot, avoid & recover from 7 start-up scuppering traps.
The Non-Technical Founders survival guide: How to spot, avoid & recover from 7 start-up scuppering traps.
