- suggestions for better outcomes by really working together
Suggestion 2: The business and its outcome is the context
Thanks to the first suggestion, we have the basis of a preliminary bridge for walking over to the other groups to start collaboration, albeit fragile and really just the start. We must continue.
Even with a shared purpose in place, specialists often have a tendency of forgetting the context, and seeing the world from their own area of expertise. They may end up protecting their professional reputation instead of remembering that the business is the context and that they have to constantly think about how to contribute to the outcome. This is even more of a risk when the specialists are working together with other specialists in the same area. They may end up doing activities in isolation...
If you are into Domain-Driven Design [DDD], it will come as no surprise to you that the business is the context. We DDDers are perfectly aware of that, of course. Business == Domain. We don’t stop there, however. Not only do we think about the business overall, we also try hard to understand its different sub-domains/bounded contexts, the relationships and think about which are the core, supporting and generic sub-domains.
Just using the company’s overall business as the context takes as sooo far compared to many whose only concern is their own speciality, for example programming. And what they don’t realize is that not only are they creating less value, it also makes them worse programmers! Oh the irony!
Another example for getting help to focus on outcome is to use XP stories and BDD-scenarios:
As a
I want to
So that --- Outcome!
Given
When
Then --- Outcome!
How come we so often see that activities are just done rather than focusing on outcome? Is it because activities are measured and you “get what you ask for”? Sure, they are often easy to measure, but that doesn’t mean it’s a good idea! There is a high risk of creating a local optima. Only use the measurement if it is perfectly aligned with the global optima and the outcome! Often we create our own worst obstacles to success!
An example that you might have experienced a variation of first hand is to measure and use the number of open problem tickets in the operations department as a basis for bonus. That might lead to a situation where the operations department prioritizes not opening a ticket, or at least not really helping the person in need. Instead the ticket is closed with a comment that rationalizes why. A typical example of local optima. Another example involves a friend who used to work for one of the big three who received a lot of flak during their bug solving week. He and his team hadn’t solved a single bug since they had no known bugs. The manager was furious since it affected his bonus.
So, let’s assume you are planning a trip abroad. There is always someone telling you to “before anything else, get yourself some sunscreen”. Well, it might be necessary… but it’s DEFINITELY NOT sufficient, it won’t take you anywhere! Let’s put that in the perspective of business development.
When it comes to business development, should you focus on being offensive or defensive? Well, just as in soccer, the trick lies in balance and adapting to the situation.That said, it’s each to their own. Some will only ever talk about sun protection. :) It’s a matter of whether people are driven by fear vs driven by excitement, improvement and evolvement.
Examples of defensive focus areas could be compliance and control of risks such as old technology, and these are about focusing on cost. Examples of offensive areas would be to find new markets and expand old. These are to do with revenue.
Of course, you can’t just choose one of them, you need a balance, just like in soccer!
That said, I personally automatically tend to focus on offensive and revenue growth instead of cost cutting. Cost cutting might actually hurt revenue, and you can’t save more than going down to 0 cost. There is no limitation for possibilities of increasing revenue.
A friend of mine has created a concept for invention creation and investigation. He told me the other day that he will give a workshop for a huge company regarding this. Ironically the preparations and setup is a mess because the company is fighting back, doing everything to maintain status quo. :)
So we’ve talked about whether to go forwards or backwards, but what should the organization look like? That is just as relevant, and you can stimulate focusing on activities or outcome with how you organize.
A typical organization might have one department for each area such as marketing, construction, development, and test. An idea is kicked off in the marketing department. It then moves over to construction, who think long and hard and deal with it the best they can - of course this includes having long blaming sessions against marketing, but held in isolation. Then the initiative moves over to development and the pattern is repeated. Lots of blame, almost no feedback. After traveling through a few more departments, the initiative finally reaches the customer.
Each step between the departments means additional friction and delays. It’s also the case that each department has its own budget which it has to motivate and protect. Again, it’s about measuring activity. And on top of that, in this example, marketing is far removed from the client which,of course, is not good at all.
I find the outcome is often far better for the second variant organization which is organized around products instead, having people from each area of speciality working together [AIOD]. You will find there are fewer delays (no departments to toss stuff over the fence to each other) and a much closer proximity to the customers. In this variant, feedback also flows more freely and eagerly.
Developers often hate this at first. “Hanging out with a sales guy? Ouch!!!” It won’t just be a matter of helping out to achieve a better outcome (as if that isn’t a lot in itself), the devs will also become better devs. And, of course, the different specialities can, and should, have their time to hang out too. Outcome first, speciality second.
“Oh, we are doing similar things in two places… That’s super expensive! :(“
Be prepared for such reactions...
If such reactions arise, ask how they would deal with a crisis situation themselves. If they have already experienced it, they might say that all there is time for is working tightly together towards the goal …! “Put everybody involved in a room, lock the door and tell them they can only come out when they are done.” So they have it in them after all… :)
Yet another gap we can do wonders with bridging is the one between business managers and developers. Just as we as developers need to learn about the business, and benefit tremendously from doing that, the managers will benefit by learning more about our area of software development. It’s our responsibility to help them with that. Nowadays the code is mightier than the sword and we have to spread the knowledge!
Let’s have a look at a model. It’s a good example of ”All models are wrong, but some are useful.” Let’s assume the developers’ interest lies in the code and the managers’ lies in money.
Yet there are similarities between money and code. For example, we write code to create value and value is measured in money. Furthermore, maintaining more code requires more developers than a small codebase does. Developers cost money.
So, a model of translating the size of a code base into the maintenance (not initial creation) cost can be very useful.
I know you can tear it down in seconds (for example “then I will write very long lines”), but you do understand the intention and it makes managers really happy. All of a sudden they understand that when you are whining about not wanting to create bad code, it’s only because you are watching over not only their maintenance cost but the possibility of moving quickly when new opportunities open up! The model may not be perfect, but it leads in the right direction!
The size of the codebase matters a great deal! A bigger codebase will drive costs, delays and bugs, and the larger it becomes, the more developers are needed. And more developers will create more code… A vicious circle. :(
Also remember the Mythical Man Month [MMM] even though it’s 40 years old. It describes a formula for how much more delayed a late project will be when one more developer is added.
One challenge with keeping the codebase small is the risk of a desire to predict the future and allowing those predictions to affect the codebase today… Predicting the future is amazingly hard. An example in the Black Swan [Black Swan] describes the controlled situation of a pool table. Even there it very quickly becomes tricky to calculate what will happen. Working out the angle of the first stroke isn’t that hard, but predicting the angle after 56 strokes requires taking into consideration every atom in the universe. Unfortunately, what makes it even harder is that the atoms also move.
When choosing between prediction and being prepared, I prefer the latter. Having a tiny codebase is a great way of preparing for the unknown and to be able to create outcome!
We now have pillars for making the bridge stronger. In the next part we will see how we can bridge the gap even more by using a certain style of work. You find it here << URL coming up within a week or two >>.
References
[AIOD] Sriram Narayan; Agile IT Organization Design
[Black Swan] Nassim Nicholas Taleb; The Black Swan
[BDD] https://dannorth.net/introducing-bdd/
[DDD] Eric Evans; Domain-Driven Design. Tackling Complexity at the Heart of Software
[MMM] Frederick P. Brooks Jr.; The Mythical Man-Month
The series published so far
Part 0: Typical problem situations
Suggestion 1: Start with the purpose
<< This >>
This is an adapted extract from the presentation called “What really matters” that has been presented in cities including London, Sydney, Hamburg, Frankfurt, Berlin, and Cape Town.
This article was originally published on LinkedIn. Join the discussion and read more here.