This is a raw mental exercise I might come back to this one day and refresh it,

While contemplating how to make G2i’s engineering more effective, I started thinking of the kind of questions that I need to answer, and this list was born.

These are questions and notes, not questions and answers.

What are some questions every engineering department should try to answer?

At first, it seems naive. But, thinking from a “questions and answers” perspective increases your clarity over a problem.

1) What kind of work does your team do?

To be able to control work, you need to first identify what work is.

• Write code for a feature.
• Write code fixing a bug in a feature.
• Write tests to help us maintain a feature.
• Write documentation.
• Write infrastructure code/logic to help us release our software continuously.
• Review PRs that are either implementing or fixing a feature.
• Review possible solutions to implement or fix a feature.
• QA new and fixed features.
• Estimate work.
• Onboard new team members.
• Plan sequence of work.
• Any non-engineering requests like calls, data requests, progress updates, etc.

I’m not trying to list everything, this might be the gulp of it.

Once we can identify what work is, we can focus on making it visible.

The problem with hidden work is that it is not only invisible but also undecided for, untracked, and unbudgeted. It is a small hole in your ship that does not make you sink but slows you down, sometimes significantly.

In order to have greater outcomes you need to focus on what work is in your production line. Where did you invest 80% of your engineering resources this last quarter?

If the work in your production line is invisible, you won’t know where your investment went into.

2) What is the value of what you are shipping or maintaining?

This might fall into the product. However, I find it important for there to always be a monetary value for each request. No matter the size, no one has an infinite number of resources. Everyone should approach tasks with a fixed appetite.

Engineering needs to determine priority not based on subjective points but based on what will yield the highest return on investment.

How do you determine the worth of tasks?

This is the hard question and I will not attempt to answer it here. It feels heavily dependent on multiple factors, like in what industry you are in plus what you are attempting to build.

At G2i, we follow a Shape-Up method where requests must be pitched. Each pitch requires a fixed budget plus duration appetite. We don’t build X. We build what we can in the time we determined it was worth spending on the problem. We can later reiterate problems that require further improvement as our appetite towards that problem grows.

But, there isn’t a perfect approach. Even if you set time as a constraint, you are bound to build something that is not worth building and thus attaching an initial monetary value plus ways to measure post-build value generation can allow you to make real-time decisions whether you should continue investing on this effort.

And the ability to change routes is essential. And why you need solid KPIs to make it clear to you when something is going either terribly wrong or well.

3) How do you measure quality/progress/success?

Is a successful rollout your final KPI of success? Is the number of tickets closed in this sprint your efficiency KPI? Are you measuring number of lines or Github contributions as a KPI for developer productivity?

We must not fall into the following trap:

What matters is not only the work you complete but also the overall impact it generates.

You can ship a new feature every week, however, if each new feature does nothing, or even worse - it generates a negative impact due to low quality software, engineering is causing issues.

How do you measure that in your engineering department? How do you measure the impact of the work you’ve done?

Interestingly, when you approach this from the product/business perspective you start to notice how developer efficiency and code quality fall under this same umbrella.

If you generate positive business impact by shipping features or fixes that results in a reliable software that meets business demands, you can rest assure your developer efficiency and code quality is ok. I am sure someone can contest to the code quality point and say how code quality might be low irregardless of the business impact, but don’t you agree that what matters will be the final outcome and not the aesthetics of the code? There is no doubt some balance to this though.

This is a very thin line indeed.

But, we must rationally measure. We have to be careful with “correlation not meaning causation”. The number of lines coded does not mean someone was a high contributor to a project.

I don’t intend to propose a solution to the overall measuring, I hope to only spark thoughts. And I also I admit I don’t have a solution, I’m still thinking about it.

4) Where does work come from?

In larger companies, it is common for work to sneak in from other departments, unrelated to the engineering’s goal.

In other times, less technical product managers can also continuously push down work that does not make sense nor do we have the budget to do.

The goal is to identify where work comes from is again to measure. The origin can help shape the value. Or sometimes it can help update the value as well, you might have implemented a new feature and you later find out it does not return as much value as perceived despite taking a good chunk of maintenance time due to bugs - would you rather keep it or remove it?

Research has shown that we have a tendency of adding instead of removing when it comes to creating solutions. Make sure you are measuring in a way to counter-weight this bias.

While engineering can not make a decision of not having a feature alone, it can bring clarity to the problem, especially around monetary cost.

5) How do you hire?

When should you start hiring?

Do you have a consistent process?

Where do you post job offers?

Who does interviewing?

How much do you pay?

How do you measure their success once they are hired?

6) How do you onboard? Do you set up your onboards for success?

Do you have a list of resources you need to give them access to?

Do they have everything they need?

How do you guarantee their success?

7) How do you fire?

Do you have a list of resources you need to revoke access to?

How do you manage team morale due to firing someone?

Do you have clear KPIs to justify your fire?

Do you understand the impact of firing this individual?

Continue

Share with me your thoughts on this. I’m still practicing this thought exercise and if you have more questions you think I should add here I’d love to hear from you. You can reach via Twitter or email.