The Startup Mindset

A startup is where all your base knowledge or all the modules you have studied as an undergraduate or masters student become immediately useful and very practicable. If you work for a startup, the right mindset is to think of yourself as a generalist. Kiss goodbye to being a specialist, if not completely then on most days. A start up is the heaven of people with a strong software engineering knowledge or degrees. I am not making a case for focusing your job applications to only startups but if you find yourself in one, relish it, learn, and step up to fill any technical or soft gaps where possible. Yes! This is a preaching about grit and malleability but not an evangelism for getting burned out. There is a balance.

Now that I have given you the summary of what this article is about, let’s dive into my personal experience being a Cloud Innovation Engineer at CloudPlexo. As the job title implies, I am mostly supposed to be doing Innovation stuff in the cloud but I find myself also doing a lot of general software engineering stuff and product management. You can say that an Innovation Engineer is a Product Manager and you will be 100% correct. To be conservative, I would say there is a huge overlap between an Innovation Engineer and a Product Manager. Both roles involve building feature matrixes in addition to thinking about what can be done better. Furthermore, you are also researching on how to leverage on existing tools and technologies to innovate- in my case, tools and technologies in the cloud. You may also be speaking to clients to understand their needs.

Innovation is mostly about thinking differently. It is also about seeing connections where none seems to exist. The best innovations mostly happen when advancements in one domain is used to make advancements in another domain or when a pivot happens. This however doesn’t necessarily happen out of a vacuum. One has to keep learning about new features of other related products, new technological trends and how they could be exploited to innovate. Therefore, keeping abreast of industry trends is vital. Learning is part of innovation work. Again, this sounds more like a product manager.

My typical week involves overseeing UI/UX meetings. Technical Code and Design Review meetings also happen once a week. This should not be mistaken for a daily standup. It has to do with the big picture of code and design. On Fridays, I train the sales team across 4 products: Back up and Restore Solution, Cloud Management Software, Learning Management System and Call Center Solution. I am also available to jump on sales meetings/calls to help, if clients need any technical clarification. I also advice clients on general cloud related technical support. This weekend, I will be implementing a Proof of Concept for an innovation I suggested related to a Back up and Restore Solution. And in between all these activities, I write white papers with at least 90% contribution.

This may seem like a lot or that I am doing things not part of my job description but I imagine this is the typical experience in startups if not the universal experience. I am talking about early days of startups. This is where grit is useful. This may seem chaotic to some people but I have been learning a lot from how to improve daily stand ups and kanbans to the right way to persist communications and decisions since a lot of decisions happen in different fragmented impromptu meeting/calls. And also hallway conversations; slack for my fellow remote workers. Decisions and code evolve very quickly, therefore, startups need to document properly. If your reaction to my last point is that you run a lean development process, therefore, there is no need to document then you must now realise that I mean that you should document the big picture.

To document the big picture, your requirements and test documents come in handy. This is an easy way to keep track of how decisions affect requirements and features, consequently, tests. Furthermore, your test documents keep track of what features where implemented together with passing and failing tests. This could be as simple as itemised requirements and itemised tests. You can also add annotations for how requirements evolved based on the meetings/calls and slack conversations or hallway conversations. An annotation tool would prove very useful. This will layer information to prevent information overload. If you communicate across teams, maintain single lines of communication to better synthesise information and keep track of the big picture. Have some structure for communication else it is easy to get lost in the world of slack hallways.

If you are in charge of teams or you report to a boss, make sure you persist key decisions and outcomes in writing where you document takeaways and connect them to the big picture in your startup. This will provide avenue for clarifying any miscommunication or misunderstanding. Verbal communications are good for fast decisions but they don’t help with untangling problems if something goes wrong or something is misunderstood. Personally, I send a a lot of follow up emails to document decisions and offer opportunity for clarifying misunderstandings amongst stakeholders. You can also use an online collaborative document where all stakeholders can view decisions and agreements and ask questions or receive clarifications. In addition to adding clarity, low context communicators will have somewhere to quickly find an answer to their questions, some sort of FAQ.

Some apps are successful largely because of their UI/design e.g Path. Path was acquired because of its design team. If you have had a conversation about softwares with me, you will quickly realise that I am a fan of clean minimalistic, balanced and forgiving user interfaces. Startups should leverage on front-end frameworks to deploy apps and maintain a simple and clean design for their UI. The same UI stacks should also be enforced across products suites and platforms. It is very okay and advisable to forgo complex fancy aesthetics for simple and reusable stunning designs. There should be a focus on how well and how fast UIs can be delivered. This is better achieved if there is a backward and forward propagation of ideas between the design team and front-end engineers.

When it comes to implementation, have an iterative mindset. Always start off with a simple design even if it means a quick paper sketch. This affords all stakeholders the opportunity to clarify their vision so that implementers will build the right solution. You don’t want to be in the situation described in the cartoon below:

If you design then you will conserve your energy; this means you are managing time spent on implementation well. By all means, resit the temptation to avoid designing on paper; there may not be restrictions on design in a startup but if you don’t do it, it may cost you another iteration, consequently, time. This doctrine also applies to the code of your first iteration. Start simple, and Keep it Simple, Stupid! (KISS principle). This helps to keep motivated and helps with delivering your sprints on time by adding incrementally as you get used to the complexity of what you are building. I am directly talking to junior developers here.

And now to the softer side of things. Having soft skills helps a lot too. On rare occasions, I find myself motivating a developer to adopt an iterative and generalist mindset. To think of abandoned solutions as experience and learned material or improved skill. Realistically speaking, even if the code you have written doesn’t make it to production, you are inching your way to senior developer position. You have gained more experience. The code may well be reusable in another setting. Therefore, develop with the mindset that your methods, subroutines or functions are going to be reusable. Ever heard of highly cohesive and loosely coupled designs? This is what it is about. Some times developers may think that they are not good at speaking to customers or the sales team when they are asked to fill an unforeseen gap but there is always opportunity to gain clarity when a developer speaks to clients. All experiences are valuable to a software engineer. And only startups readily afford all these experiences, I dare say.

Since roles in startups are not necessarily clearly defined, I am now going to comment on your immediate manager as a developer in generic terms. If you find that your manager asks you to develop a feature while focusing on scope, time and budget without getting a bit deeper into the design details then your manger is thinking like a project manager. Don’t be frustrated, you can use designs to nudge your manager to get into details a bit more to understand his/her vision else you may likely have a lot of implementation that doesn’t make it to production. The opposite of this is your manager acts as a product manager. In this case, your manager goes two to three levels deep into the details, for example, focusing on how well and best to deliver features. The “power gap” here is less and you may likely understand your tasks better at first instruction. This is still not an excuse to run away from creating designs before implementation. I am only suggesting an insight about how you reason about your manager. Reasoning properly about your situation helps you to manage your emotions well, consequently, your energy.

I love meeting with clients and sales team because it helps with innovation. It gives you an eye into the frustrations of customers, which could be avenues for opportunities; new features or improvements. It is very important not to try to bias the mind of the customer in order to get good feedback. In as much as committing a client to buying your product is key during sales calls or meetings, one must also listen to all the nice to have features the customer is talking about. Even when you don’t close a sale, ask customers what would have made them to buy the product. Offer to build the wanted feature if it is feasible. It is okay to take a bet on your clients. Time will tell if that feature is going to survive or get killed at some point. Know when to realise that a feature is a vanity idea at any point of its life from ideation to the refinement phase.

Depending on your philosophy, this is something you may not want to talk about but it is a need to know. Now that funding is drying up in the technology space, you may experience the dreaded salary slash or the living allowance slash. It could be as high as a 50% slash. You have to love what you do. It is important to stay motivated and remember the big picture. You are learning a lot and also helping solve a teething problem. I am not making a case for sticking to a job that doesn’t pay your bills. This is not a financial advice. I am only saying that it might be something you have to contend with as growth in the tech space stalls. No one knows your financial situation more than you; make the best decision for yourself.

To conclude, most of the information I have shared here are from my personal experience working as a Cloud Innovation Engineer.
I believe this to be representative of happenings in the startup space. This also corroborates information in articles I have read and also anecdotes I have listened to.