Since becoming a tech lead, I’ve been trying to figure out how to do my job. What do I do here?

This blog is a product of that effort. To codify and share the results of that learning process.

So with that, I want to discuss the central theme that I have come to orient my work towards as a tech lead. That theme is feasibility.

Why Feasibility?

Why do I orient towards feasibility?

I feel it’s a natural outgrowth of the organizational design of my company. We borrow a lot of ideas from Marty Cagan and Silicon Valley Product Group. So at the lowest level in the product organization of my company, we are organized as cross-functional product squads.

The squad I work on is composed of a product manager, product designer, myself (tech lead), software developers, and a test engineer. The product manager, designer, and tech lead, together form a product trio.

The product manager is primarily concerned with value and viability, whether or not the product meets the needs of the business and customer.

The designer is primarily concerned with usability. Can the intended user figure out how to use the product?

The tech lead is primarily concerned with feasibility. Can the solution be built?

What is Feasibility?

So what do we mean when we talk about technical feasibility?

Oxford defines feasibility as “the quality of being possible and likely to be achieved.”

Seems straightforward. From that definition, it seems as though I could answer the question to most projects I’m involved in with a yes or no answer pretty quickly, just based on my gut.

However, there’s a little more to it than that. Much is implied in this definition. What makes something possible? How do I know what’s possible and what’s not? What are the constraints that make something likely to be achieved? What are the hidden constraints that haven’t been considered?

Marty Cagan puts it this way, feasibility is about whether engineering can “…build what we need with the time, skills and technology we have [emphasis added].”

Time.

Skills.

Technology.

Those are the elements that I focus on.

I’ll attempt to address each of these elements in turn. In reality, though, they are entangled together and must be approached holistically. When you choose to optimize for one element, you may be doing so at the expense of another.

Time

Judging from experience, I think a pretty common misconception is that feasibility is the same as an estimation of when the project will be done. Often a stakeholder might ask what the feasibility of a given feature or project is. But what they are really asking is “Hey, how long will this thing take?”

Feasibility and timeline estimation are not the same. Feasibility may incorporate some element of estimation, especially as a factor when comparing options and deciding a direction. However, they are two very different disciplines.

At my current company, we operate according to the Kanban methodology.

So while the timeframe isn’t without importance, it is secondary to providing value. If the thing you’re working on is indeed the next right thing, It should be focused on until completion.

There are times when you have some work that has a fixed delivery date. In this case, the goal of the feasibility analysis is to come up with a plan to hit a target.

So for feasibility analysis, my main concern with the time element is determining what the relative size of our implementation options are. Option A might take longer than option B, but it accounts for X, Y, and Z concerns. Option C might be faster than all the other options. However, option C comes with such and such trade-offs to consider. Understanding this informs our decision as a team about which avenue of implementation to venture down.

As we further decompose the work, we may be able to perform some projections. The projections aren’t meant to imply fixed-date commitments, but to inform decision-making along the way.

There’s a lot that can be written on estimation. And has been! I plan to distill what I’ve learned about software estimation into a future post.

Skills

Skill is just the ability to do something. There are several dimensions to consider when determining if your team has the skills to practically execute a project.

Probably the first obvious dimension is technical skill. Does your team have any experience with the tech stack of the project? If the project calls for building an API in Java, and the team members have been working in the .NET stack for the past five years, you’ll have a learning curve that must be factored in.

And I say the team on purpose. To use the previous example, it may be that one of the team members did tons of Java API development at their last job. But if the other team members haven’t, that team member is going to be spending a lot of time training and communicating rather than coding.

Aside from specific technology, there is the craft side of software engineering. Think algorithms, design patterns, data modeling, architecture, requirements analysis. All of the skills that transcend languages and frameworks.

The greater the difference is between the team’s technical expertise and the expertise demanded by the project, the more this becomes a limiting factor.

A closely related dimension to technical skill is experience. Do you have a team of junior developers? A team of more seasoned veterans? Or a mixture? The more robust that the solution for the project is required to be across any given set of quality characteristics

A third dimension is domain knowledge. How familiar is the team with the business side of what they are attempting to implement? Do they understand the user’s pain? If you’re tasked with implementing an accounting system, it helps to know the jargon that accountants use. The members of the team have to be able to take the concepts from the domain, abstract them into a model, and then translate that model into instructions that a computer can understand. The more understanding and context that the team has of the application of the system they’re building, the more accurate their implementation will be.

Another dimension to consider too is the team’s experience together. Has the team worked together long enough that they have had time to gel, to get to the point where each member could almost finish each other’s sentences? How’s the sense of trust on the team? The practice of building durable teams has gained popularity in recent years because there are so many advantages of having a team that has a shared history and experience.

There does come a point where the team and the project just aren’t compatible due to a mismatch between the skill-set of the team and the project’s requirements. In this case, you might:

• Scrap the project. Possibly reevaluate later.

• Request work or assistance from another team that is capable.

• Reevaluate and see if there’s another solution to the problem you’re addressing that is practical for the team.

Technology

When it comes to handling the Technology aspect of feasibility, I view it as answering a series of questions…

Within our existing technology stack, do we have something already that can solve this problem?

If we do have something that kinda’ fits the problem, but not quite, what is involved in modifying or extending that system to meet the problem? How difficult would this be?

Do we need to build something entirely new?

Can we buy a solution?

If we can buy something that meets a portion of the need, can we build the other portion to make up the difference?

Whether we build or buy, how does that integrate with the existing system?

Is working on that integration going to be harder than just modifying the existing system(s)?

That’s just a handful of examples I can think of. Answering these questions takes at least a couple of skills. You have to be able to apply some principles of software design and architecture. And you have to take an investigative approach.

Applying software design and architecture involves being able to map a customer or business problem to a possible software solution. And then use knowledge of various methods of software construction to work out a possible design for that solution. Or better yet, several alternative design options.

This is informed by a few things. An understanding of your current system. An understanding of the technology ecosystem that you work in; for example, what similar projects are available in your company to draw examples from? What services or APIs are available? It’s informed by experience; what have you built in the past? And Informed by education; what techniques and design patterns have you formally studied? What’s the latest innovation you’ve read about on TechCrunch or some other outlet?

I say “investigative approach” because I often feel like a criminal investigator from a TV show. I’m always gathering bits of information here and there. Especially with legacy systems; they’re almost always poorly documented. So you have the evidence of a design, the code is there. But the story of how it got there, how it works, and how you have to work with it to do the thing that you want to do with it… all of that may be a complete mystery. One that you have to solve.

I might be compiling notes from Google searches about the latest technology. I might be scouring through source code, maybe even downloading and running an application with a debugger. I might be walking up to someone’s desk and asking them questions. The point is I’m constantly compiling data from disparate sources and attempting to synthesize that into information that can help myself and my team understand what’s possible technically.

How do I “do Feasibility?”

So we know a bit about what feasibility is… how do we go about determining whether a project is feasible or not?

At the beginning of the project, I will direct my activities towards drafting a feasibility analysis report. This gives me a document where I can record answers to questions like the ones in the previous sections, and share the outcome of my research with the team and any stakeholders.

I treat it as a living document. It will continuously be updated and amended throughout the project as more is learned and decisions are made and changed.

The document isn’t just built by myself, of course. I’ll go over it with fellow engineers, my product manager, designer, stakeholders… anyone with information or vested interest. Their input helps further refine the document. It’s very much a collaborative effort.

I have yet to find a generic template that works for me. I’m open to suggestions, so if you have one, feel free to leave a comment! I’ve been developing different versions of a template as I’ve been doing this kind of work more formally.

What ends up in the feasibility report is usually some variation of the following

1. An overview of the options.

2. Potential trade-offs between the options. Pros/Cons.

3. A recommendation of which option.

4. Some additional context and background.

I’ll also put links to supporting documents as well. These might be architectural diagrams, architectural decisions records, conversations logs; anything that might be relevant.

I consider myself to be done with the first draft once the document answers enough questions about the implementation of a solution to a problem so that the development team has a solid basis of information upon which to begin implementation.

Now aside from feasibility analysis, there are other important aspects to my role as well. I view the tech lead role as a mixture of project management, software architecture, technical advocacy, and being a player/coach. Yes, even still coding. I plan to write more posts that are specific to those functions in the future.

So that’s a snapshot of where I’m at in this journey. I hope for anyone in a similar position that sharing this sparks some ideas and maybe even helps you to move from clarity to ambiguity, wherever you are on your path.