Conversations to make technology work better for people

To improve our game, it seems useful to become more aware of how we do what we do. And how we perhaps do things differently than others and how this could possibly be valuable.

Ruth Malan architects visually, Tom Graves makes tools for change, and Peter Bakker sketches maps. My friend Marc makes fantastic concept diagrams. Obviously, they do a whole lot more, but these seem to be their specific ways of doing what they do.

So how do I do what I do? What’s specific about my way of working?

I read a lot. I enjoy reading non-fiction books and can relax doing it. So I read a lot and, increasingly, listen to audio books. That helps me look at things from different angles and sometimes make valuable non-obvious connections.

Interesting, perhaps, but not a specific way of doing things.

After much soul searching and thinking back to significant moments in my career, I came to this conclusion:

I talk to people.

Oh, wow! That’s disappointing. Underwhelming. And not exactly a differentiator as billions of other people do it, too.

Also a bit of a surprise as I can be comfortable with silence and by myself.

But it is what it is. And that is what it is. Or at least a part of it.

My biggest contributions to value creation have come from conversations. Sure, I’ve written good code, made effective design decisions, and wrote decent architecture documents. There were some useful acts of management and leadership. Of followership and fellowship, too.

But the most profound benefits came from good conversations. And the most damage from bad ones. One set of conversations profoundly changed my life for the better and continues doing so every day.

How can I have more good conversations? And fewer bad ones?

What makes conversations effective? Or efficient? Or enjoyable?

What do we need to do beyond talking shop? How to avoid turning into a talking shop?

What’s a conversation anyway? How can we have valuable conversations beyond the synchronous, spoken, face-to-face conversation? How do we make asynchronous conversations work? Written conversations? Conversations mediated by technology? Or other people?

And coming back to purpose, what conversations do we need to have to make technology work better for people? In business, at work, in private life?

Technology as tools and techniques? Technology as an industry? Technology as an organisational function? Technology as a career?

How to make these conversations worth having?

Now you!

This good be a start of conversation. Perhaps even a good one. Let’s try this!

I said the stuff above. Now you say something in response. And then I’ll respond to that. And then you…

I don’t have a soundcloud but I’m thinking about writing a book:

Satirical book cover looking like an O'Reilly book with the title "Talking to people: unique results from doing what everyone else is doing" by Oliver Baier

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:

Toggl: efficient time tracking for individuals and teams

Note: I do not receive any payment or other commercial benefit for writing this post.

I’m an indie consultant and need to track the work I do for multiple projects and multiple clients.

My needs are simple:

  • Time tracking needs to reliable, and
  • It needs to get out of my way.

Toggl is a great fit on both counts. It’s built by a small company headquartered in Talinn, Estonia, so I don’t need to worry much about privacy concerns — GDPR not only applies, but is enforceable relatively easily.

My approach to time tracking is simple: Toggle allows me define clients and projects associated to the clients. When I start to work, I start the tracker, select the project and write a short description of what I’m actually doing. When I stop working, I stop the timer.

There are several built-in reports which give me all I need to invoice my work effectively.

In fact, Toggl allows you to do much more. For example, it supports time-tracking for teams. It also allows you to pre-define tasks and track time against pre-defined tasks (useful if you have submitted a task-based offer). I currently have no need for any of these features.

I use Toggle on the web, my Mac and my iPhone. It just works, is easy to use and hasn’t failed me so far. Toggl’s subscription fees are very reasonable.

Toggl’s support people are highly knowledgeable, very friendly and quick. I think I have only ever contacted them to discuss minor feature requests — I don’t think I’ve had any real problem yet.

I see me being a customer for years to come.

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.