Category Archives: Practice

What I do and how I do it. Also, why and where. Posts on my evolving professional practice.

Improving performance in small and medium-sized businesses

I root for small and medium-sized businesses. I enjoy discovering people with great ideas and watch them learn and succeed. Perhaps even grow, although I’m very skeptical of growth as an objective in its own.

The way many SMEs respond to the current COVID-19 crisis is so much more inspiring than what many of the large corporations do — or fail to do.

Improving performance to me is getting more of the outcomes I want and less of the outcomes I don’t want while expending reasonable effort.

Just like the rest of us, many of these businesses could do with some help.

Effectiveness and efficiency — there’s a place for both

One important step towards performance improvement is understanding the effectiveness and efficiency are not the same thing and that there is space for both of them. Even very small businesses benefit from distinguishing the areas in which to focus on efficiency from those in which to focus on effectiveness.

Wardley Maps can help with this — particularly with helping people realise that there is a common and unavoidable evolution process from the very first realisation of an idea to its commoditisation.

Tom Graves’ blog post Building effectiveness in a small business is a great start for thinking about the architecture of the enterprise.

Awareness of the development process

Thinking about one’s own development process is essential. I’m not only talking about software development — which most businesses shouldn’t do most of the time anyway — but the development of any idea for a product, service, process … well, anything.

There are thousands of development, design and delivery processes to choose from. Some of them show original thinking, many of them are bland variations of a common theme.

A good place to start is Tom Graves’ Explore, Expand, Exploit blog post followed by his Change Mapping book.

Same – same, different – different — minimum viable discipline for free thinkers and fast movers

I do get it: People set up their own shop to free themselves of the shackles of corporate life. To be free to do the things that need doing. To be independent from far-away decision-makers with little understanding of what’s happening on the gorund. To be able to move fast.

This is great. Props to you.

To keep doing this, we need to make sure that the stuff we built yesterday doesn’t come tumbling down tomorrow. Otherwise, we’ll be busy with emergency reponse and fire-fighting instead of serving our customers. Clearing the rubble left of our business instead of building our business.

One simple way of building runway and bringing a little discipline to your business is keeping similar things similar and keeping different things different.

This brings clarity to your business. This helps build and maintain conceptual integrity and cohesion. The principle of separation of concerns plays into this.

A very small amount of discipline can take us a long way — even without going full corporate.

A trivial example:

I keep all my business email accounts in Outlook and all my private email accounts in Apple’s Mail on all of my devices. This prevents me from sending private emails from a business account and vice versa.

This is not perfect as I could still fail in sending email to one client from another client’s email account. (Some of my clients like to keep control over project communication.)

So what?

What of the above resonates with you? What doesn’t?

What performance challenges are you facing as a small business? What’s growth got to do with this?

Things change — pointers to handling time-variant data

Things change. Deal with it. And make sure your systems deal with it, too. This may mean not changing data even though things change.

Handling time-variant data can seem complicated. Not handling time-variant data appropriately can lead to real problems for your organisation or your clients.

Smart people have been thinking about this for a long. A few good concepts can take us a long way.

To get up to speed, read Martin Fowler’s Temporal Patterns.

After that, you may wish to read Developing Time-Oriented Database Applications in SQL by Richard T. Snodgrass. This book is out of print, but a PDF is available from Professor Snodgrass’s publication page.

It’s time to rediscover analysis

Analysis seems to have fallen out of favour years ago. In a world fascinated with the move fast, break things mindset, nobody had time for analysis. A quick discovery, a dash of design and sprint of coding will do.

People moved fast and, well, broke things — including things that clearly shouldn’t have been broken.

Over on Twitter, Michael Nygard said:

And Arnaud Bos back him up:

Do yourself a favour: go back and read that short document by Leslie Lamport. I’ll wait.

In this spirit, it’s time to rediscover that analysis has value — understood as the study of the problem space. It is complementary to design — understood in a narrow sense as the study of the solution space.

Remember that business analysis (as used in IT circles) is a misnomer: business analysis usually includes functional design (or conceptual design).

Analysis needs design as we can’t analyse a problem’s solution into existence. But it also has always been true that design and delivery need analysis as a meaningful solution must be based on thorough understanding.


So, does analysis matter to you? Is this only a theoretical discussion with little practical value? I’d love to hear about your experience in this space.


Peter Bakker replied on Twitter:

Autonomy isn’t absolute, not even in ‘autonomous’ teams

It can’t be. And that’s a good thing.

Unless stuck on a deserted island by themselves, no team is autonomous.

Once we come to terms with this realisation we can relax a little and see the extremes propagated by some in the autonomous teams discussion for what they are.

An example — contrived, but potentially usefuly

Consider a small team designing, building and running a digital service and owning all day-to-day decisions. They release what they want to release, when they want to. It’s all serverless, so they don’t have to worry about any in-house infrastructure.

Superficially, this sounds like a fairly autonomous team. But if we’re honest, there are dependencies all over the place:

  • Someone has to provide minimal administrative services, so the team get’s paid and stays out of trouble with the tax and social security authorities.
  • The team depends on the banking system or some alternate form of payment services provider so customers can pay them.
  • They rely on utilities such as electricity and internet providers to power their laptops and connect to their cloud services.
  • They rely on web browsers or operating systems and the standards they’re built on that their customers are using.

This is a minimal example that isn’t nearly complete. Yet it shows that even a team in such a contrived setting can’t truly be considered to be autonomous.

Once the team has acquired customers, these will have opinions on the type of changes the team can make without alignment. If the team relies on outside funding, the investors will have opinions, too.

As the service becomes more successful, the team will find it difficult to do all product work by itself. Setting up a second team will become unavoidable (in practical terms).

At this point, these teams are interdependent and the fiction of autonomy is should be laid to rest.

Dependencies can be beneficial — if managed effectively

Growing some more, new focus areas will emerge: we’ll see diversification in the administrative and support work as well as in the product work. The company will be starting to build a platform, supported by one or more teams, on which other teams deliver their (parts of) products.

And that is alright. This has benefits. And if you’re in this for the long haul, there doesn’t seem to be a reasonable alternative.

Interdependence Day — all day, every day

Interdependence is a fact of life, and — it seems to be — essential (though not unique) to who we are as a species.

So let’s work on becoming aware of this interdependence, shaping it, having more fruitful and less detrimental forms of interdependence.

But please spare me the waffle of fully autonomous teams and the contortions some suggest to achieving this aspiration of autonomy. I’ve seen more damage caused by well-meaning folks falling for this than from any hard and inconvenient dependency that was managed only half decently.


Related posts

See my mini-series on Shaping software development teams, in particular autonomous teams vs. technical integrity of shared components for a great tweet by Simon Brown.

Other voices

Failed #SquadGoals: Spotify doesn’t use “the Spotify model” and neither should you.
By Jeremiah Lee, 2020-04-19

Have your RFP reviewed before issuing it!

Some RFPs are much, much more effective than others. _Effective in allowing respondents to provide a meaningful response_ to the issuer that helps the issuer to progress with their initiative.

// There’s a discussion to be had whether RFPs are a good approach to getting what you need as a client, but that’s a different topic and a different blog post.

I’ve seen too many ineffective RFPs in my career. Colleagues have praised me on creating meaningful responses and developing workable project designs from “almost nothing”, so I’m not writing this post lightly. But some RFPs won’t work as issued and can’t be made to work.

The real risk in issuing an ineffective RFP isn’t receiving no responses — it’s receiving ineffective ones. Some suppliers will respond to RFPs as issued, fully aware that the work can’t reasonably delivered as requested — and making provisions for it in their response. Depending on your experience with such proposals and the related projects as a client, you may be able to spot these provisions and you may be able to manage the resulting negotiations during the project. Often clients are not sufficiently experienced to do this effectively.

There’s a big risk to service providers pointing out the deficiencies in issuers’ RFPs: bad news often aren’t welcome and many competitors will be happy to provide a response to the RFP as issued. It takes courage not to respond to an RFP in the expected way and warn the issuer of risks. As an issuer, you can’t rely on all service providers being willing to take that risk for you.

We’ve raised such problems with issuers in the past, and some of them decided to rework and re-issue their RFPs. Scrapping an RFP is exceptional and expensive in terms of attention, time and money — although not as expensive as embarking on an ill-conceived project as some of the other issuers have found out the hard way.

Fortunately, there’s a relatively easy way out of this situation:

As an issuer, have your RFP reviewed by an external party who will not bid on this work!

The effort for this is small compared to the effort of creating the RFP and the overall tender process — let alone conducting the actual project.

For even better results, involve this external party throughout your RFP creation process from early on. Preferably as advisors collaborating with you throughout the process and thereby helping to build experience and skills within your own organisation.

If you decide to execute a project and that an RFP is the right way for you to select a service provider, you might as well make sure your RFP is as good as it can reasonably be.

Tech teams, be valued more by doing less!

I keep seeing technology teams trying to do far too much by themselves. Running their own hardware, patching their own operating systems, fiddling with software infrastructure, building their own monitoring and alerting solutions and building custom applications.

Sure, some businesses may have to do some of this, or can demonstrate clearly how these activities provide benefit over the alternatives. Most don’t.

A dangerous approach: running to stand still

As a result, these teams always have too much to do. The urgent prevents the important from getting done. The teams are running to stand still.

It seems to me that teams often gravitate to custom approaches in an attempt to stay relevant to their organisation, and thus to secure their jobs and livelihoods. I can’t blame them for that. Unfortunately, the opposite happens: firefighting and routine maintenance leave little room for creating the outcomes the organisation depends upon in order to thrive.

As a result, people on the ‘business’ side of the house become increasingly frustrated with the technology teams’ inability to deliver. The technology teams are working hard to just keep the lights on and feel treated unfairly. In short, a lose-lose situation without any winners — except for the competition.

A scary change

The way out of this situation is counter-intuitive and perhaps somewhat scary:

Technology teams need to do less in order to be valued more!

Doing less means spending _less attention, time and money_ on activities providing relatively little value (ie benefit in relation to cost) to the organisation.

This means: Buy, don’t make. Increasingly, buy means buying a higher-level service rather than a product.

This allows the technology teams to spend more attention, time and money on activities providing high value to the organisation — usually activities that enable real and meaningful differentiation.

Delivering more value more consistently helps the organisation thrive. Others will appreciate this and value the technology teams and their contributions more. As a consequence, their relevance to the organisation increases and their jobs and livelihoods become more secure.

Making the effort count

Despite the title’s false promise we’ll still have to work Fridays — sorry, not-sorry for the click-bait. But since we have to put in the effort anyway, we might as well spend it on something worthwhile.


On ‘valuable’ work

Parts of this post are somewhat clumsy. The draft had much better flow when I wrote about ‘high value’ and ‘low value’ work — but that wasn’t what I really wanted to say!

All work done by humans should be valued, and we should definitely value all the people working with us. What I meant by ‘value’ was the relation of resulting benefits to the costs incurred in terms of attention, time and money.

In areas in which we do not seek differentiation, we will typically focus on efficiency, ie achieving good-quality outcomes for reasonable effort. There are limits to the benefits increased expenditure on accounts receivable accounting can yield.

Nonetheless, this work must be valued, and the people doing it must be valued and treated well. Keeping the lights on all day, every day requires as much skill, creativity and dedication as developing the new version of our flagship product.

The COVID-19 pandemic should have made this clear to everyone by now.

This post still is somewhat problematic with respect to the use of ‘value’ and ‘valuable’ work. I’d be grateful for suggestions for improvement.


Related posts

Borrowing from Service Blueprints for Wardley Maps

Having used my first Wardley Map successfully with a client, I’m obviously qualified to have opinions and entitled to share them. So here we go:

The horizontal axis of a Wardley Map maps an element’s stage of evolution. This axis is divided into four different areas: genesis, custom-built, product/rental and commodity/utility.

The vertical axis maps the value chain and elements are placed according to their level of visibility to customers on a continuum from visible to invisible.

This seems to work great.

I realised that I have seen another type of diagram that uses the same idea for its vertical axis: G. Lynn Shostack’s Service Blueprints. See this version by Nielsen Norman Group for a more recent take on the subject.

Not all of these layers seem equally applicable to Wardley Maps, but if we want to be more concrete than fairly visible or quite invisible, adopting the notion of front-stage inter-actions, backstage inter-actions and support processes could well be helpful.

Rather than re-inventing the wheel, I’ll give this a try when I want to be more specific on customer visibility in my future Wardley Maps.

Fast help: Two days architecture workshop

I’ve had the opportunity to participate in and at times lead architecture workshops with clients over the course of my career. In small, mid-sized and large companies, covering the entire organisation or only a single unit, from a narrow technology focus to a broad, interdisciplinary enterprise view.

In my experience, two days is an effective duration for such workshops. Interested participants are usually able to clear their calendars for most of the time, it’s long enough to do meaningful work, and it’s short enough to maintain focus.

An additional day of pre-reading, preparation, planning and alignment makes such workshops much more effective.

Another day or two of investment will provide you with a high-quality write-up of results and recommendations, including the opportunity to follow up on issues that weren’t covered fully during the workshop.

More and more people are beginning to seriously consider new ways of working as a result of the COVID-19 crisis: These workshops can be done remotely and do not have to be two full, consecutive days. They can be divided into 90–120 minutes slots and spread across a week or two.

This format is equally relevant to end clients and intermediate service providers. It’s effective during project initiation as well as in ongoing projects as outside support to delivery teams or as part of delivery assurance. It can be done as a collaborative design effort, but sometimes reviews or assessments are necessary – but even these can be done in the spirit of collaboration and in a manner that keeps all involved safe.

Two days of concentrated workshops, no more than a week of a consultant’s effort can provide real results, fast.


Related posts

Sensible defaults – expressing opinions under uncertainty

Clients (and managers) often ask for specific advice when I still know very little about the situation at hand. And I can’t blame them for that – the pressure is high, time is short, we need to see some progress.

In Not having all the answers I said I preferred understanding the situation before expressing possibly ill-advised opinions. I still prefer this today.

A recent experience made me realise that I might be able to do better than shrugging my shoulder and saying ‘Let me look into this’ even when faced with client questions even under high levels of uncertainty.

True enough, after saying ‘It depends’ I usually explain what factors a decision or recommendation depends upon – but perhaps only deferring a statement is somewhat lazy.

I’m beginning to think that the idea of sensible defaults may be applicable in this context, too. In configuration, a sensible default is a default configuration value that keeps users safe until they make a decision to modify the configuration setting – hopefully with positive effects.

How could I provide sensible answers quickly to clients yearning for a response to pressing questions at a time when I don’t know much about the situation yet?

Sure, I’d still point out the preliminary nature of my answer, highlight its inherent risks, and emphasise my preference for looking into the issue in a little more detail. But in many situations I might be able to go beyond ‘It depends’ with things like: “In what I believe to be somewhat similar situations we chose red and orange gummy bears over the green and yellow ones and we were quite happy with it.”

Not as good as a well-researched answer, but much quicker – which is important to clients in many situations.

I will challenge myself to go beyond ‘It depends’ in situations of uncertainty if:

  • so desired by my clients
  • I think I can keep my clients safe even when providing a preliminary answer
  • and that answer has a reasonable chance of being relevant, ie it’s more than guesswork.

I already dread how uncomfortable this will make me feel. There be dragons…but there may also be value.

Fast help: RFP analysis for service providers

In Three key takeaways from Humble Consulting by Edgar H. Schein I mentioned Schein’s observation that consultants often provide the highest value to clients in the early phases of the consulting engagement. I wondered whether I could focus on such high-value work in my independent practice.

Analysing requests for proposals (RFPs) and developing an initial solution approach and response strategy for other service providers could be such a high-value activity:

RFPs often aren’t as clear as they could be and meaningful responses and effective solutions are often not obvious. Technical experts and other specialists often struggle in such situations.

Usually, I’m able to extract an RFP’s essence – ie its purpose and context – and express it in terms that enables collaboration among the entire bid team quickly. This often removes obstacles to effective contributions from experts and specialists.

To be more concrete, in my experience, it is often possible to

  • Review an RFP,
  • Identify initial sets of questions, assumptions, constraints, risks, issues and dependencies,
  • Develop initial ideas and high-level options for a response, and
  • Develop initial ideas and high-level options for solutions

within four working hours. Obviously, this depends on the size and nature of the RFP – some require much more work, others take even less. These ideas and options are necessarily vague and preliminary – they need collaborative detailing and validation.

This can be interesting to consultancies and IT service providers in several scenarios, for example:

  • Need to augment available specialists’ perspectives with a generalist’s view
  • Overcome the initial “What could we do with this?” hurdle
  • Desire for an independent assessment, ie a second opinion
  • Insufficient capacity or experience

So much for the initial idea. Next step: a first value proposition.