Leading technical projects: the SkillLab Way

Photo by Giulia May on Unsplash

Planning and shipping features in a startup are all about navigating in uncharted waters. It is exciting, uncertain, demanding and requires agility and precision.

Every growing startup faces the question: How can we optimize our approach to plan and execute features most effectively?

At SkillLab we are interested in optimising our engineering process to ensure the success of the product, while supporting engineers in their career growth and avoiding burnout. Over the past year, we defined the framework for leading technical projects and we have successfully executed it over past quarters.

Key considerations that guided our framework:

1. Every engineer should have the opportunity to be a “tech lead”. From the start, we strongly believe in giving engineers the opportunity to lead projects regardless of their level and background.
2. The framework should maintain our agility. Since we have a small engineering team (<20 engineers), we can leverage our size to make quick decisions, ship things fast and not be blocked by long processes. Therefore, it was important for us to not introduce another process that adds extra blockers such as writing very long documents, waiting for approvals, etc.
3. Empower tech leads with ownership. While responsibilities are a list of certain things an engineer is expected to do, ownership encompasses all the things an engineer proactively does without being assigned to: taking initiatives, questioning the status quo, and offering proactive solutions. Encouraging all our engineers to ask “why” and “do we need this?” becomes even more effective when they recognise their role as owners.

Starting with why: Product Roadmap Forum

“Collaboration” is one of the core values at SkillLab, and it is reflected in all our processes. One good example of this is Product Roadmap Forum

Every quarter, we pose an important question: “What should we work on in the next quarter?” Rather than leaving this decision to a select few, we believe it’s a dialogue every member of SkillLab should engage in.

The ideas for features come from diverse sources: our internal teams, be it UX or engineering, our prospective clients, and feedback from our existing partners. After gathering the ideas(during previous quarters), we host a Product Roadmap forum where ideas are presented by each team pushing for it, emphasising why we need to do it and why we need it now.

Roadmap Proposal:

After collecting all the inputs, product managers choose what to work on next quarter based on the overarching vision, the urgency, and the technical feasibility, and move the rest to backlog. The chosen features are demoed in Roadmap Proposal, where, based on factors like engineers’ availability, domain expertise, and career aspirations, every project is paired with its “tech lead”.

First kickoff: UX / PM / Tech Lead

In the first kickoff meeting, three stakeholders are gathered together: the product manager(PM), the UX designer and the Tech Lead. In this session, the UX designer goes over the mockups to provide a visual projection of the feature in alignment with business objectives. This is an initial design overview for the engineer to have a “big picture” of how the final result will look like.

Technical Planning:

The planning for each epic begins several sprints ahead of its kickoff. This includes initial research and preparation of the technical plan. Each epic can vary in its technicality, but the technical plan roughly consists of several parts:

• Context
• Technical scope / non scope
• Database design
• Affected APIs
• Rollout plan
• Security checklist
• Metrics
• Open questions

In developing the structure for our technical plan document, we built upon existing research, as detailed in the Pragmatic Engineer Blog.

Points to Remember for Technical Planning:

• Adaptability is key: we know how it goes, you plan for something and find a better way to do it during execution. Should you stick to the plan? Of course not. It is primarily to offer a clear vision for pre-execution and to share this vision with others.
• Avoid over-planning: Given the point above, we don’t want to overthink during the planning phase. Usually writing a technical plan takes 1–2 days, but it can vary based on the project's complexity and the tech lead's background and expertise.

Dev Crit: Getting feedback

We finished the technical plan document — it is a piece of art.

So, what’s the next step? Opening the floor to feedback.

While engineers can always provide asynchronous feedback on the document, we prioritise organizing a dedicated synchronous feedback session known as “Dev Crit.” In this session, the tech lead navigates through the document, placing emphasis on “open questions” to encourage insightful input. This is also a valuable session for other engineers who work on the same service to be aware of what is expected to change.

Caution: While it’s tempting to include more voices in the Dev Crit, remember that sometimes, fewer participants lead to more focused and productive discussions.

Execution

Planning is done, and tickets are ready. Now it’s the fun part: execution!

The effectiveness of the execution process depends heavily on communication. Therefore we agree on some logistics beforehand:

• Leverage Team Channels for Updates. Centralising updates ensures everyone is aligned and can easily trace any changes or decisions.
• Optimize Standup Time. While it is tempting to dive into details of the complex problem you solved in standup, it is better to share updates based on their broader impact.Ask yourself, “What does the team truly need to know?”. This will guide your sharing and keep standups concise yet informative.
• Showcase Progress Continuously. Schedule a few demos for team during the sprint. Regular, even if incomplete, demos allow us to share progress, catch issues early, and maintain momentum. We save that “perfect demo” for the client, but among us, share and celebrate every milestone of the journey.
• Don’t struggle alone. Remember, everyone wants the project to succeed. When facing to a blocker, raise your voice, talk to your manager, or pair up with other engineers. The biggest mistake facing a problem is keeping that to yourself.

Frequently asked questions:

1. I am a junior engineer with less exposure to system design, how can I lead projects?

Regardless of level and experience, there is always ambiguity around technical planning. We need to emphasise that the “tech lead” is not the person responsible for making all the decisions, but she is responsible for initiating discussions, raising awareness during uncertainty, gathering feedback from other engineers, etc.

Example Scenario: A senior engineer might be able to design the system but lack expertise on how to implement a specific UI feature. Therefore it's important to get input from someone who has more exposure to the front end, and make the decision together.

2. There are too many things to do, and I have no idea what to do!

The idea of leading a project can quickly jump from feeling overexcited to feeling overwhelmed.

The scope is uncertain, PM estimates the feature to be shipped in 1 sprint, the designs look like something from a Black Mirror episode, the staff engineer mentioned some technical terms and you nod your head while guessing what it might mean.

Photo by Aarón Blanco Tejedor on Unsplash

First thing to realize is, this is normal.

This is what learning and growing in your role looks like.

The more you are exposed to discomfort, you will grow the skill of managing it.

That being said, feeling overwhelmed can bring a spiral of negative thoughts and self-doubt. And the problem with self-doubt is its self-fulfilling prophecy:

Self-doubt → emotional overwhelm → lack of clear thinking → low performance

Here are several practical steps I use to reduce overwhelm:

1. Break down what is overwhelming you. Write them down as bullet points. Break down each bullet point to open questions.
2. After step 1, you can see what are the pain points. Is there too much load on your shoulders? Decide which ones are crucial for the success of the project, and write down what can be delegated.
3. Talk to someone in 1:1, preferably an experienced engineer. Share your thoughts on the project, including what you wish to delegate and what parts you have no idea how to do. You might be surprised to hear that, actually, the hardest parts might not be hard at all, and your colleague has done something similar before! :)

And most importantly, remember this:

The difficulty is the point. I find that I can handle ambiguity when I internalize that this is the nature of the work. If it wasn’t messy and difficult, they wouldn’t need you. So, yes, you’re doing something hard here and you might make mistakes, but someone has to. The job here is to be the person brave enough to make — and own — the mistakes. You wouldn’t have gotten to this point in your career without credibility and social capital. A mistake will not destroy you. Ten mistakes will not destroy you. In fact, mistakes are how we learn. This is going to be OK.
- Tanya Reilly, “Staff Engineer’s Path”