Failure to Launch: Don’t treat Developers as Labourers
This was a story I wrote back in 2020 and chose not to publish. But I changed my mind.
I was consulting a startup recently. They had a very ambitious product that needed to be built on iOS, Android, and Web. They had a rich feature set too with a lot of fancy UI and analytical features. The management had budgeted for only 5 engineers, After analyzing the entire feature set, my primary estimate was 8 months for a beta launch taking time for RND and QA. My primary responsibility was to provide technical guidance to this project and make technical decisions.
What happened
Management wanted to launch in 4 Months
This was the first red flag. After going through the timeline, management said, that is too long and asked me to redo the timeline if they added 2 more junior engineers. When I did my recalculation, still, the launch date seemed to be close to 7 months. Then further discussions were made and I recalculated the timeline again, taking only the basic set of features required by the application to complete the critical functionality without fancy UX elements and nice to have features. This trimmed down the time further, and I took the optimistic route with assumptions where UX designs will be provided in due time and developers put an extra effort over the course of 4 months with less RND work and fewer bugs, the application with critical functionality seemed to be doable.
If you have had the time to read Startup Owner’s Manual by Steve Blank and Bob Dorf, they have listed 9 deadly sins when building a new product in a startup taking Webvan as a case study. And of those sins, the 3rd sin was Focusing on a Launch date. The launch date shouldn’t be driven by marketing executives and investors picking off a date in the calendar, but rather, the date should be fixed according to the duration of when the product engineering team estimates a complete product can be shipped. And these dates need to be flexible as sometimes wrong turns, research and development may cause more delays than anticipated. The product needs to released only when ready without cutting corners. Fast-tracking product development to meet a pre-determined launch date and releasing a half-baked product will only damage your brand and reputation.
Enforced strict policies
In my opinion, startups need to be super flexible. Startups consist high functioning individual who needs their freedom and space to perform optimally. This is key if the project release is 4 months away with a mountain of tasks lying ahead. By adding corporate policies like, come to the office every day, work from 8 am-5 pm, 30min lunch break, etc is not going to help speed up the product delivery. The engineering team took this a bit negatively as some had longer commute hours and sometimes, it really didn't make sense to come at those said times. I would have rather focused on outputs and deliverables regardless of the employee IN times and OUT times.
With COVID, one of the groundbreaking realizations for many organizations with software engineering teams was, remote work was truly efficient and productive. There are situations where you may want your entire team in one room to plan something or design something, but more often than not, WFH really works and brings the best out of us. In my personal experience, the other team I work with within my main organization (Platformer), We work completely remotely, collaborate when needed on zoom calls, and focus on deliverables rather than the time worked in a day. For example, there were times where my team members would go offline to run a couple of family errands, but they would 100% deliver their tasks in due time. This flexibility eases the pressure off of them and gives them the freedom to plan their day and work accordingly. However, I understand this may not work for some cooperates and larger teams, but I believe this setup is ideal for startups.
Time Tracking leading to Micro-Management
With my recommendation, the management decided to provide WFH to developers and asked them to come to the office 2 times a week, preferably Monday and Friday. This was a great step forward and I saw the enthusiasm and motivation increase within the team. By letting them come to the workplace a couple of times a week works better because it helps with team bonding and chemistry. But Alas! this was short-lived as a memo went around asking the engineers to set up a time tracking software and switch it on every day when they start working till they end work. Now, time tracking makes sense to a lot of people, but I am an avid hater of time tracking. I understand, investors, management sometimes may need to have an understanding of what their employees are doing in their work hours. But I see this as an invasion of privacy, like someone watching over you supervising every step you take. It is a very negative feeling and I really hate it and I believe many developers would agree with me. (Probably project managers are shaking their heads at this point). But I recommend timesheeting instead, which has a much more positive intent. Management wants to know how much time is spent on given tasks and the developer has the power to now log time against a task for the duration it took. This is more encouraging and promotes positive intent.
With the release date looming closer, developers definitely have to put in a bit of extra effort to reach the deadlines. Without motivation and drive, this is hard to enforce. Because of the time tracking software, developers are now bound to ONLY work 8 hours a week and that’s it. Suddenly the number of tasks completed didn’t start to matter as long as developers worked 8 hours. In my opinion, the only thing that should matter is the tasks and deliverables, whether the developer completed it in 4 hours or 16 hours in a day shouldn’t matter as long the deliverables are met.
Change Requests
In an Agile fashion, development teams need to adjust themselves to respond to change requests. Initially, when doing the timelines, it was decided that no priority will be given to nice to have features and fancy UX elements which would take considerable development and RND time. But management constantly came back with change requests on UI, UX, and functionality which led the team to revert certain decisions they took architecturally and redo some of the code. This is completely okay in an agile fashion and this is how we do things. But not when you have a 4-month deadline where management comes up and completely changes UI unnecessarily or add unnecessary features that don’t really add value to the critical functionality of the application. And it didn’t make sense when the management took my recommendations lightly and asked the engineers to reprioritize those features and still expect the project to be released in the original timeline. I was honestly at a loss for words at this point.
Development teams should welcome and anticipate change requests in any project. But they should also be mindful of how change requests may incur delays and affect the timelines and clearly communicate with the client and meet at a common ground on what’s feasible.
Promises Unfulfilled
When agreeing on a 4-month timeline, it was agreed upon that management would provide UI/UX screens on due time and a couple of junior engineers and a QA engineer hired to support the team. However, UI designs were always late which blocked the engineers on many levels and the Junior engineers were never hired. QA engineer was hired in the latter weeks of the project, along with management wanting to make multiple UX changes, taking the QA engineer's input.
Now, what happened last was okay. If the UX is bad according to the QA engineer’s input, the UX should indeed be changed. But what I would recommend in a project like this is to validate wireframes and UX flow first before implementation, because changing things around after implementation always takes time.
The Blame Game
3 months in, the engineering team was in shambles. Nobody had any motivation or enthusiasm. Everything seems to be black and gray. Early delays were made because UI screens were late, which was to be provided by the management. Once the UX flow was finalized, functionality and architecture were designed. Then the UX flow changed from time to time as mentioned in the previous section. This led to more changes and more delays. When nearing the release date, instead of working with the engineering team, management started blaming the team, citing they are incompetent and not up to par, when they actually spent hours working on the changes and trying to bring the impossible to life.
Pushed over the edge
Developers were finally pushed over the edge with no appreciation, asking to come to work on weekends and blaming them, and talking in a demeaning fashion. There were constant talks about how the marketing team is working hard and bringing in revenue whereas the development team is just burning money. People were demoralized and were pushed over the edge where all of them decided to hand in resignation and look for other jobs.
In my opinion, it is unfair to compare marketing and development teams. Product development is an art and it takes time. It’s an investment you make for the future of your organization. If you are looking for a quick cashout, maybe developing a software product should not be your priority.
The Next Steps
One of the key issues in this entire ordeal that I identified was, developers were treated as laborers. I believe, they should have been treated as assets instead. These were very good engineers with tremendous skill and capability. As an organization, the management needed to understand that these engineers are hot in the market and it would be just a matter of time they would leave if they are not happy.
The book Drive: Surprising truth about what motivates us by Daniel H. Pink explains this beautifully. Dan argues that it’s time to go back, give workers autonomy, a purpose, and the freedom to master their craft, so we can go back to being as intrinsically motivated as we were as kids — an approach he calls motivation 3.0.
It was management’s responsibility to make sure such a situation never arose by taking care of engineers properly and provide a positive environment. It is actually the simple things like appreciation, trust, flexibility, and freedom that matters the most. You need to trust your engineers to do their job. Sometimes from the investor’s perspective, it may be hard when a large investment is poured into the development team and you are looking for results and outputs every day. But to me, building software is an art, and it needs time, freedom, and flexibility to finesse it.
What could I have done differently as a consultant
Initially, I wasn’t aware of the organization's policies or the mindset of the management. Therefore, during the hiring process of the engineers, I told them my vision of the culture that they are expected to experience, which was further from the truth as I realized that I have no say in the culture and the management already has decided on policies and how things would run.
I was only available as a consultant on technical delivery and I did give my feedback and recommendations with regards to policies and culture when things were getting off track. A project manager was hired and I gave up team management to that person, but that person never got along with the engineers and suddenly they were divided into sides as management and development team. The project manager sided with the management playing the blame game with developers. I could have been more engaged and shielded the engineers better as a consultant.
UX changes hit so many delays in the application, and I should have pushed for a QA engineer in the early days of the project and validated UX flows with the QA engineer before implementation.
Getting things back on track
With a demoralized team looking to quit and look for other jobs, it is a bit hard to get things back on track. However, my recommendation, as I have already given them is to stop the blame game, build up a positive environment, appreciate the people and acknowledge the hard work they put in and go easy on the strict policies and be more people-oriented than process-oriented. Start trusting your engineers more, listen to their reasons, and work with them on a postponed release date, rather than forcing them to work nights and deliver the impossible. Stop with random changes that don’t affect the critical flow of the application and work on those changes after the first release in a prioritized order. We can still get things back on track, but the management needs to change their mindset on how things are getting done in the software industry.
Your feedback is appreciated
Let me know your thoughts on what other things I can do to get things back on track and what I could have done differently to change the outcome. Your feedback is greatly appreciated as I believe all of us have room to grow and learn.
Cheers!
Update
Couple of months later the entire team decided to quit and the company doesn’t exist anymore as of 2022.
