Opinion Post 10 mins Rob Sandbach Focus for Success: How to Find Your Software Development Niche Every startup goes through an exploration phase of trying out different products or services, pricing, and verticals. And then they focus on one combination that works well for them and successfully scales within their home market and key verticals. We know that because we went through it. As Indiespring has grown, we’ve gone from a full-service digital shop for everyone to zoning in on what we do best. We leverage our skilled designers and developers to just build apps and websites. And even that was far too broad. Over the last couple years, by talking to our customers, we’ve uncovered a clearer elevator pitch — we create bespoke mobile-first products for tech companies. We realised that this time of uncertainty can make the role of a CTO — or CEO in a smaller org — a really chaotic one. You find yourself juggling too many projects and stakeholders. Having to balance managing a growing team, building and following through on a roadmap, and pursuing cleaner code is challenging enough. The less focus you have, the harder your job is. Not just for CTO. Think of the strain it puts on sales, marketing and HR, whose jobs it is to sell your business. Has your startup or scale-up gone through this exploration and transformation? Today we talk about ways to help you find that all-important focus, so you foster a company culture that is motivated and aligned in the same direction.Focus ain’t easy: Don't get distracted by greenfield projects. Developers love to learn! New languages. New skills. New infrastructure. They are an experimental, curious bunch by default. That’s why we love them! But this is a double-edged sword. Dev’s love greenfield software development projects that offer them the creative freedom of a tabula rasa. You don’t have to deal with existing constraints or integrating with existing architecture. Most early-stage companies start with either leveraging a SaaS or a PaaS to build on top of or by going greenfield. This is great at the prototyping stage when you are working on a minimal viable product (MVP). Or creating a previously unused app or ecommerce website. It also works if your project is completely rewriting legacy software in a new language or framework — like moving from a monolith to microservices — where you are retaining none of the original codebase. On the other hand, greenfield development for anything more than a prototype gets expensive. Allowing autonomy and creative freedom for your developers can lead to choices that are very challenging to integrate with current code. While innovation sandpits at enterprises are wonderful places for ideas to grow, their purpose is usually to be eventually planted right into the main codebase to better serve customers. We discovered our niche because often ancillary greenfield projects — like customer-facing apps for ecommerce brands — distract from the ongoing brownfield tech projects of our creative agency clients. Eventually design decisions have to break out of the experimental and become part of an overall organisational strategy. And you need your full team on board. Embrace autonomous alignment and agile architecture. How to build it — so they will come — is just as important as discovering your market specialisation. After all, Conway’s Law reigns supreme. Either your architectural design will shape your team — or your agile structures will shape your architecture. You don’t want either turning into a sloppy bowl of spaghetti. This is why Netflix has famously set up guardrails not gates that allow employees to make decisions within the company’s best practices. Also notably, at the world’s most famous streaming service, managers clearly focus on the ‘what’ and developers on the ‘how’, which has been proven to create a partnership that lets everyone move business objectives forward in a safe and reliable manner — without anybody going off the rails and deleting important code in production. Spotify’s engineering culture achieves similar by balancing alignment, autonomy, and accountability. Autonomy is a clear motivator for most creative workers like designers and developers. Autonomy is intrinsically linked to employee engagement. But autonomy can lead to ambiguity, inefficiency, chaos, and unstable code. Even in the safe-to-fail tech world, developers have to be held accountable for their work. As the Harvard Business Review writes, “A company has to establish a strategy and a purpose that provide context for employees’ actions.” This may still find employees self-organising, but within the constraints of objectives and key results (OKRs) with continuous, shared measurement and short feedback cycles. The C-suite or team lead sets the shared objectives and individuals create the quantifiable key results that support those goals. And these goals shouldn’t just be customer or code-facing. Recruitment and inclusion goals are just as important. A team culture isn’t built overnight and you need both the teammates and them to feel welcome to truly participate in it. Create goals and values that benefit your team. Once you’ve decided on your target audience, what you’re building and your basic architectural and language choices, it’s time to communicate the overall goals and strategy. Company wide. Before you go mapping out an 18-month plan, bring all your stakeholders to the table. Identify the values of your organisation. Not just of your product, but of how you will serve customers and, most importantly, how you will serve your teammates. You must together set a goal that, as Management 3.0 puts it, aligns constraints by being: Simple Measurable Achievable Relevant Time-bound Then you need to express these values to your team. Heck, even post them on your company LinkedIn or About Page, so you have to stand behind them. Written goals are more likely to be achieved. Make sure you have real instances and stories that help explain and exemplify these values. And that you consistently acknowledge when you identify something that fully supports — or even goes strongly against — your company values. Aspire to be sought after. People want to love to come to work. People want to work for companies that people love to work for. Sounds simple, but it’s easier said than done. By fostering this type of trusted, safe-to-share culture, you also open that up to external partners and, most importantly, customers. It allows you to bring customers left, closer to the planning and agile feedback cycles, so you actually build what they want. From design to development to demo, you can show trusted customers what you are building and gain essential opinions and uncover critical edge cases upfront. It assures early on that you are actually building what your customer wants. And don’t forget customers are essential stakeholders in your roadmap planning. The world can’t be a locked box anymore. Publishing your roadmap not only helps cultivate trust, it makes it more likely you will deliver it on time, attract new customers, and new teammates. Of course, if you are really building what your customers want, maybe you don’t even need a roadmap. Lean software development founder Mary Poppendieck argues that roadmaps are an apparent sign of an inefficient team. An organisation can easily measure its output, which means it can only achieve so much in a given amount of time — usually measured in a sprint. Without a backlog, teams and even organisations stay focused on the opportunities they want to pursue right now — or within the next six weeks. That means you then are only focusing on what solves very ‘now’ customer demands. Instead of tasks, Poppendieck says you are better able to focus on managing throughput, workflow and immediate value, not efficiency. Unless in an open source project in which a long backlog shows a keen audience, demotivation can grow alongside backlog length. It’s psychologically draining to always take on more than you can chew. You never feel that sense of accomplishment. And burnout is ever-pending, especially now when people are working more than ever. We never want our creative workers to go back to feeling like code monkeys. By allowing developers to say ‘Yes’, ‘Soon’, or ‘No’, you’re giving them an immediate sense of control over their schedule and the intrinsic reward of delivering things that better serve customers today. Having a clear mission, vision and strategy makes it easier to attract and retain teammates, creating one of those coveted workplaces that everyone wants to be at. Added bonus is that your customers are happier too because you are building what they want, faster! To Conclude By aligning your teams values with your customers goals and creating a focus on delivering a platform that is based around both of these, you will deliver high quality work, that adds value to your customer and empowers your team to make decisions and take control of their own work. This is challenge tech leaders should be rising to and where we can push the capabilities of our teams to new levels.
