By Stephan Schulze
In software development, there can be a somewhat adversarial relationship between product or project managers and developers. Product managers are disappointed when they find out their feature will take twice as long to build as they had hoped. Developers are irritated when they’re given deadlines that have no ground in reality.
But essentially, we all want the same thing. We want to do meaningful work at a successful company and take pride in our achievements.
And how do we do that? By understanding the value that we provide. If my work doesn’t help my company, then what’s the point of my job?
But to understand the point of your specific job, you first need to understand your company’s general reason for existing.
Companies ask themselves the same question: what’s our value proposition?
It’s not just employees who are grappling for a sense of purpose. Whoever started your company had to, at some point, answer the same question “Who are my customers, and what value can I provide them?”. After all, investors want precise answers to questions like these.
Aside from the detailed revenue forecasts and market predictions, a company’s value proposition needs to be expressed in an easily digestible mission statement.
For example, here’s the mission statement for my own company, Project A:
“We invest in excellent teams and foster expertise by providing operational support and creating an environment of success.”
It’s pretty simple, but it’s easy to extrapolate more specific goals from that one value statement. Here are some more examples from a few leading tech companies:
- Microsoft: “Our mission is to empower every person and every organization on the planet to achieve more.”
- Uber: “We ignite opportunity by setting the world in motion.”
- Google: “…to organize the world’s information and make it universally accessible and useful.”
- Tesla: “…to accelerate the world’s transition to sustainable energy.”
If you work for a middle to a large company, just stop reading for a moment and think about your company’s mission.
- Can you recite the mission statement off-by-heart?
- Do you know where to find the mission statement?
- Does your company have a mission statement at all?
If you don’t know your company’s mission statement, I’ll explain why you should be aware of it. If your company doesn’t have a mission statement at all, I’ll explain why you should insist on one.
All meaning flows from the mission statement
Everything you do, you should be able to tie it back to your company’s mission in a really concrete sense.
A negative example: Google starts selling cat food
For argument’s sake, let’s take Google’s mission to organize the world’s information. Suppose that you work for Google, and your boss asks you to work on a new e-commerce platform. But it’s a platform to sell Google-branded cat food. “Our new Google cat food is the future,” your boss proclaims. Maybe people would buy it, but the idea is kind of weird, and it has nothing to do with Google’s mission. You probably didn’t take a job at Google so you could help the world’s cats get access to delicious treats.
It would be at this point where you should ask your boss: “Does this align with our company mission, or is this just your pet project?” (sorry for the terrible pun).
You have the right to know what your mission is
In the real world, I assume that most of you have never been asked to work on a project that strays so far from your company’s purpose (if you have, we’d love to hear about it in the comments). A more likely problem is that your company is still unclear about its mission. Indeed, many younger companies that we work with don’t have a clearly defined mission statement. Or they’ve thought of one, but they haven’t made it clear to their employees or broadcast it to the outside world.
If your company hasn’t yet worked out its mission, you should feel within your rights to challenge them about it. If you need data to back you up, have a look at comparably.com. Comparably provides data-driven employer profiles — these profiles include data about employee motivation in relation to a company’s mission. For example, take a look at Google’s profile — specifically employee responses to Google’s mission statement and values. It shows that 70% of Google’s employees who provided survey responses are motivated by their employer’s mission, vision, and values. They’ve also written a great article on mission statements and values, which I definitely recommend as supplemental reading.
But while a mission statement is an essential first step, it’s not enough to provide any technical project with direction and focus. After you have your mission defined, you need to define strategies and tactics for carrying out your mission.
Every game plan needs strategy and tactics
To compare and contrast these concepts, let’s take a look at another kind of game: Chess.
The website Chess Fox provides a great definition of tactics and strategy:
Chess tactics are mostly known as a forceful combination of moves–whereby you win material or give checkmate. Such decisive tactics usually become possible as a consequence of an oversight (blunder) by either of the players.
Chess strategy, on the other hand, refers to the long-term objectives you want to achieve. In other words, strategy requires planning but tactics require calculation.
Or, as a former chess champion put it, “Strategy requires thought, tactics require observation”.
A strategy example from one of our own projects
In a previous article, I talked about a project where we helped a German tour operator migrate their website. What I didn’t emphasize in that article was that most of this company’s business comes from offline bookings. They sell tours on the phone or via mail order. They promote their business primarily through brochures and other forms of offline advertisements. However, consumer preferences for how they book tours will slowly change, and they’ll need to invest more in their online business to become competitive.
This is a clear strategy: modernize the e-commerce part of the business to maintain a competitive edge.
A counter-example with no strategy at all
In contrast, suppose that you run a regional bouncy castle business that is doing just fine with offline promotion and a minimal website. Let’s also say that you have a business partner who is ambitious but impressionable. This business partner envies his friend’s business. The friend’s business has a website that is powered by a fancy CMS — it allows people to book and rent power tools online. Your business partner wants to get the same CMS for your website. But why, though? It might make it easier to book castles and accelerate orders, but you don’t have the staff to keep up with a huge increase in bookings, and you weren’t particularly looking to grow much bigger anyway. Plus, the CMS is super expensive and not worth the extra cost. This would be a project with no strategic justification.
Don’t work on a project if you don’t know the strategy
What are you working on right now? Is it part of a larger project? Having read these examples, which one matches your project more closely?
If it’s the latter, I encourage you to put down your tools and stop working right now. Seriously. Why would you work on something that could turn out to be a complete waste of time?
At Project A, we have the values “obligation to dissent” and “fix now, don’t complain later” enshrined in our list of company values. This means that everyone has just as much a right to question strategy decisions as anybody else.
You should encourage your team members to do the same. Many voices are louder than one. Indeed, I have been in many meetings where developers have argued passionately about the pros and cons of certain architectural decisions or the technical demands of a certain feature specification. Why not channel that energy to question the bigger picture as well?
While we’re on the subject of architecture and specifications, let’s look at tactics
Examples of Tactics
As you might remember from our chess metaphor, tactics are “…a forceful combination of moves–whereby you win material…”. You make a move, observe the results and update your tactics based on what you’ve learned. This is essentially the idea behind agile and iterative development.
Tactics then spawn concrete tasks. Here are some examples of tactics and their resulting tasks.
Increase conversion rate by 10% by improving the payment process.
- Reduce the number of required steps from 6 to 3
- Add a timeline to show the progress
- Fix Javascript bugs X, Y, Z
Migrate to managed Kubernetes.
- Create a Terraform configuration
- Migrate QA, Staging, and Production to a new Cluster
Set up user management.
- Implement basic setup (roles, users, permissions, password) for creation, deletion, updating
- Create user registration
- Create password-forgotten functionality
Optimize the process of creating invoices.
- Automate the manual steps in the invoice creation process
But as you can see, the tasks begin to pile up once you start itemizing your tactics. All of a sudden, you have a backlog that contains 1,371 actions. You need some way of prioritizing these actions, and primarily this is the product manager’s job, but they can’t really do this job without input from development.
Calculate the ROI for each tactic
For each tactic, you need to know the Return On Investment (ROI). An ROI calculation requires two main ingredients:
- Business value — This is provided by the stakeholder and might be expressed in terms of savings, increased efficiency, or an uptick in customers. But ultimately, it is up to the stakeholders to put a financial value on the project.
- Costs — This is the part where developers usually provide input. The estimation of costs depends on the project. If you’re developing a new tool from scratch, you might look at developer hours and calculate an hourly rate. If you’re looking at licensing an enterprise software solution, you’ll take into account the licensing costs as well as the costs for implementing and maintaining it.
Now, I won’t go into the intricacies of how to accurately calculate the ROI for an IT project. There are plenty of people who have written about that already. Many of them are IT consultants. Let’s just say, for now, that the ROI estimates are accurate.
My point is that it has to be visible to everyone. Every developer needs to know this information.
Here’s a concrete example of cost analysis done as a “tactic” to save infrastructure costs. Specifically, the project involved migrating to managed Kubernetes instance.
You can see that according to estimates, costs would already be recovered in the 5th month, and the tactic would bring continuous cost savings after that.
However, let’s consider the DevOps engineer working on the ticket “Create terraform configuration”. Maybe they were taken off their favorite project or a project that they are under pressure to complete. They might feel annoyed at being switched around so much and would have every right to question this tactic. But if you show them the business value, they can see how this tactic fits into a wider strategy of saving infrastructure costs, and they can see that the savings are indeed significant. So why not get it done as soon as possible?
How to communicate the ROI to engineers?
If you use JIRA, you could put the ROI calculation into the description of each epic ticket. You could also put it in Confluence or any other system where you store your feature descriptions. In our case, we have the business value calculations in a Google Sheet, which is shared with the whole team. Each of their projects is listed, with a business value calculation, as you can see in the following screenshot:
Meaning flows right down to the work
Of course, you can’t spend all your time strategizing, planning, and debating. At some point, you have to make a cut and get to work. What I’m trying to convey here is that the best workflows from a clear mission and a well-defined set of strategies. This concept is best illustrated with what I’ll call the “inverted pyramid of meaning”:
The higher-level layers influence all types of work at your company, whereas the lower-level layers are going to be more specific to each team. Work that is disconnected from these high-level layers will tend to be less effective and will include many false moves.
Whatever task your developers are working on (or any employee, for that matter), they should know which tactic the task relates to. They should also understand the business value of the related tactic, the tactic’s parent strategy, and how that strategy fulfills your overall mission. If people have trouble tracing meaning back to the top layer, you might want to look at how meaning is communicated in your company or identify which tactics or strategies need better definitions.
Perhaps you’re already doing this intuitively. Or maybe you’re still getting there. Do you feel that you and your team are motivated according to this hierarchy of meaning? If so, how are you implementing it? I’d love to hear your views in the comments.