The Introvert and the Startup

feetPerhaps nowhere is the phrase “one size fits all”  more misplaced than when talking about work environments and company culture. This is particularly true if, like me, you just happen to be something of an introvert.

At startups with aggressive growth and targets to hit, we try to foster a culture in which people have the opportunity to contribute their strengths and abilities, whilst creating an environment in which they want to spend a significant amount of their time. We also want to have some fun to offset all the hard work.

The creative options and flexibility for doing this at small startups simply can’t be matched in the wider corporate world, so it is no wonder that startups tend to have some of the most enviable work environments and cultures.

But getting it right involves a complex interplay of factors when catering for a diverse workforce, and talented people bring their whole personality to work. Tweak one environmental or cultural aspect to suit certain people or to get results, and you often find you’ve ruined another aspect for someone else. Worst of all, you may even hamper their ability to contribute.

There is perhaps no group that this applies to more than introverts, as many startup environments can be somewhat charged up and geared towards the high-energy needs of extroverts.

introvert, noun /ˈɪntrəvəːt/

A person who is more energised and stimulated by spending time alone or in low-key situations, than with others, and who finds certain group interactions exhausting.

To my amusement, I find it easier to tell people that I’m gay than to admit being an introvert. The former rarely causes a ripple. But the latter is often the start of a grand inquisition: “What’s an introvert?” “Why do you say that?” “You don’t seem like one” “We don’t need introverts here” “You just need to come out of your shell and let your hair down”… All precisely the kinds of confrontation an introvert wants to avoid at any cost. It’s no wonder we usually try to fly under the radar.

It is said that people are hard-wired somewhere on the introversion / extroversion spectrum, or we learn it very early on in life and it can be incredibly hard to unlearn. This has certainly been my experience. But what we are rarely told are the upsides to being introverted, particularly in environments you might think it would be a weakness, such as at startups. Indeed, a mix of introverts and extroverts may be the ideal team configuration… but only if handled thoughtfully.

So what are some of the unexpected strengths of introverts?

  • Leading – Many famously great leaders report being introverts; Bill Gates and Abraham Lincoln among them. Perhaps introverts make good leaders because it didn’t come naturally to us, we had to learn it and tend to have a more considered leadership style that we adapt to the needs of those we are working with. We also have less of a tendency to micro manage, choosing instead to let people exercise their abilities and prove themselves to us.
  • Presenting, Explaining – Strangely, I have no difficulty standing up in front of 200 people to give a presentation or to explain a technology. But after presenting, being part of the audience as a crowd can suddenly seem daunting to me. This is perhaps the opposite of what you’d expect.
  • Listening, Insights – Introverts tend to develop good listening skills. We have a tendency to step back from crowds, or to remain at the edges. We also spend more time processing what has been said to us, less time interrupting and, because we naturally need breaks from engaging, we are more likely to spot connections and insights.

But what do introverts find harder, and what might we need adjusting in work environments and culture so we can thrive?

  • Discussion, not Confrontation – Discussions that turn into confrontations, or environments that verge on being boisterous, can be tough for introverts. We tend to retire rather than engage, feeling shut down rather than fired up. The precise opposite of how extroverts react. When discussions stick to facts, rationales and explanations rather than the raising of voices, introverts can actively and even energetically engage and, as mentioned above, may have an entirely different set of valuable insights to offer. Conversations can still be very animated and productive.
  • Space to Recharge – We tend to need time in which we are likely not to need to engage with others, so we can digest, consider and recharge. We also need the physical space to do that in. If an environment is socially charged non-stop, introverts can rapidly be worn down, drained and become detached.
    Good environments allow a mix of engagement and focus, with meetings and work spaces kept separate where possible. Some would say this limit on engagement is a downside, preferring constant communication instead, but I’d say it naturally timeboxes interaction and forces more considered work to be scheduled. No-one, not even extroverts, can stay engaged, communicative and effective the whole time. Open-plan spaces can be a drain on everyone, not just introverts.

So perhaps the strengths we’re recruiting for in fast-paced startup environments might occasionally come aligned with a personality trait we’ve usually considered to be a weakness: introversion.

Introverts comprise up to one-third of the total workforce, so getting things right for a mix of personality types could be a significant win for startups looking to build great teams and great places to work. And if startups can get this right, the wider corporate world might follow.

Headspace: Perhaps the Most Urgent Thing?

londonNothing of any significance or impact was ever created by a scattered mind.

Great things are not built in a rushed series of truncated thoughts, punctuated by distractions. They are created by getting the headspace to go deep, to stay there a while, and to surface with new insights, structure and conclusions.

Even with a eureka moment, a spark of brilliance or a chance connection, those initial insights take focus and refinement to develop, distill and simplify; to make them usable.

In fast-paced modern work environments, it’s clear that most of us aren’t managing to achieve headspace or to go deep into our work with any regularity. Our days seem like a series of distractions, email, phone calls, chat, meetings and being ever-available. Busy-ness, and particularly visible busy-ness, is a medal we seem to wear with pride.

But it’s likely that we’re barely scratching, then re-scratching, the surface of the work in front of us. We’re probably repeating large portions of it, as we absorb the cognitive switch away and back again. If we’re lucky, we’re gradually making progress in the right direction, though it will be hard-won, inefficient and lacking any real insight or depth. We may find ourselves achieving most of our meaningful work outside of office hours, which implies our work environment isn’t… well, isn’t working.

Most worryingly, we may be killing our ability to innovate, to compete and to deliver value… which is surely why we’re at work in the first place?

After 20 years working in teams, I spent a year working alone on two startup ideas… yet initially I still found it hard to focus. Surely, I had assumed, headspace would be simple to achieve alone?! It seemed that the learned expectation of interruption and the numbing array of possibilities to do other lesser things to get a hit of achievement kept me from focussing deeply for any duration. I had become a busy-ness and achievement junkie. At first, I seriously wondered whether I had some kind of attention deficit problem and so I turned to tools like the Pomodoro Technique to regain my headspace.

I gradually learned to commit to 25-minute periods of focused work, during which I would let nothing else (including my own thoughts and other interests) distract me, and then to take a short break or work on something less involved. Before long, I could crank out 6-10 of these “pomodoros” per day without too much struggle, and my ability to focus on my own returned.

During that year of regular focus, the work I produced felt significant: I made leaps forward, created two products and wrote my own UI framework. These achievements would never have been possible in my usually-scattered frame of mind. All of them were the result of focus and depth… of finding regular headspace.

Even more so in teams, the ability to carve out periods of headspace is key to getting work done together. But balancing it with being available on-demand is also crucial. We simply can’t schedule the needs of other people and the wider team, nor block them out to pre-determined times. But perhaps, after a landslide of unscheduled requests, we can push back a little, pop on a pair of headphones (a visible sign of focus), and get 30 minutes of focused work done before accepting more outside input. Oscillating in this way between being available and being focussed allows a portion of our time to be allocated to deeper work, even if we have to be a little creative and flexible about precisely which hours of the day that ends up being.

Respecting Headspace: It may seem that getting immediate answers from colleagues, and being available to provide them ourselves, keeps a work environment moving at maximum speed. But there is a cost to the team, and therefore to the project, for that immediate answer, paid in terms of the headspace of the person providing it. It may feel as if asking in-person is more productive and that chat or email are inefficient ways of getting an answer, but those tools allow the person providing the answer to crank out a series of such answers during a quick break from other work, and perhaps still within a relatively short timeframe. More urgent interruptions can still take place, but they must be balanced with the permission to block out further interruptions for a period of time that each person chooses themselves. Our headspace and their headspace will rarely occur in-sync.

Deserving Headspace: There is a flipside to this. In order to be allowed to focus, we must also prove ourselves capable of handling those queued requests in a responsive and reliable manner. Ignoring emails and not scanning chat channels for updates occasionally are certain ways to force people to interrupt us with more urgency, to grab our attention and to destroy our focus. If people learn that we will always respond within a reasonable timeframe, they will happily learn to queue non-urgent work for us.

Respecting the headspace of others may improve the output and depth of work produced by the whole team, by reducing cognitive switching. It probably also doesn’t greatly delay the answers our interruptions require, and it can be mixed with much more interactive sessions, standups, meetings and brainstorming to get the best of both worlds.

Headspace in teams, but also alone, isn’t easy to achieve. But what’s clear is that without it, the work we produce and the things we create will be mere shadows of what we’re capable of.

Maybe headspace and our ability to focus really are, somewhat counterintuitively, the most urgent things of all?

 

Image: (c) 2015, Ian Cackett

 

“Someone” Doesn’t Work Here Any More

someone

“Someone should fix the…”

“Someone will need to…”

I hear it all the time. I even say it. There is always so much for “someone” to do.

But “someone” is a problem: A cause of forgotten issues, broken links, missing pieces, out-of-date documents, poor integrations. “Someone” clearly isn’t working.

“Someone”, when uttered, tends to mean “not me”. A way of shrugging off the item, of distancing oneself from it.

We need to ban “someone”, and instead…

Find “someone”… or a team. Or nominate one. We should make sure they will take on the issue, or put it on their list, without dumping it on them. We should check they will own it. We should look on it like a baton handover in a relay race, rather than the throwing of a grenade from a-far.

Make “someone”… if there is no-one specific. We should make a placeholder list for issues and items in the same category. We should make sure a person or team picks them up at the right time, or keep a prominent record of those lists for review. We should make sure they are easily found and not lost. This is often necessary before hiring the first person in a department, such as marketing. A placeholder list might be needed for that team, until they exist.

Become “someone”… The ultimate, is to become the “someone”, for issues we could tackle or own, or just be willing to hold until a more appropriate “someone” can be found. Sometimes this means becoming “someone” in conjunction with another person, because these are often the difficult items that require collaboration and pushing forward to completion, particularly if they fall between the remit of several teams.

In rapidly-growing startups, particularly, we all collectively need to step into the gaps between teams, the places that aren’t owned by anyone or any process yet, and fill them. There can be a lot of “someones” in startups, if we aren’t careful.

The truth is, unless we are all “someone” from time to time, then the task will default to our other favourite friend, who is always more than willing to take it: “No-one”!

The Three Hardest Words: “I Made This”

dish“I made this”, is what we say by implication when we publish, send, launch, perform or unveil work that is entirely our own. Three wonderful, difficult and daunting words.

We are the only ones who can choose when — or whether — to say them, whether to hit “publish”… whether to take the risk.

Solo entrepreneurs, writers, bloggers, artists, performers, artisans all know the feeling. But even in a team at a small startup, we may feel this to some degree because we may singlehandedly represent some entire aspect of a company, a product or a service.

Our work represents us. Once we unveil it, it is out there and usually can’t be retracted. There is no-one else to stand behind it, to share the blame or the praise. No large corporation to take the flack. No anonymity. It’s like publishing a condensed version of ourselves; a snapshot of what we are currently capable of, warts and all, for the world to see.

It takes nerve to accept feedback – good, bad and indifferent – and still stand by our work, to discuss potential improvements to it, or the inevitable choices we could have made. There is no perfect launch and nothing is ever truly “ready”.

The crucial thing is realising we did our best at the time, that no-one is 100% correct, and still being glad that we put it out there. It takes guts to realise we will inevitably want to retract, delete, smash it to pieces, or to endlessly correct it based on feedback — or the perceived feedback of indifference — but to keep it out there anyway, in its original form.

So far, I’ve done this with two software products I developed alone, this blog, photographs and other articles. I have friends who have done it with startups, artwork, experimental new food products, books and performance art. I’m proud to count myself among them because I think people who have done this are amazing.

I’m convinced that we learn more by putting our work in front of an audience than we possibly ever could by thinking and agonising about it in private, by tweaking it and waiting until we feel like it is somehow worthy or “ready”. Those lessons feed back into our next attempts, but only if we make our first attempts.

If you’re in doubt, it’s probably ready. So take the leap, and say “I made this”.

Hitting Software Deadlines: Essentials Only… then Upgrade

From “Deadline” can seem like a dirty word, in the software world. But without them, our work wouldn’t see the light of day, get an audience or have an impact. So despite their perceived unpleasantness, I’m all for them.

We tend to plan work towards a deadline in ways that ignore two inherent truths about software development, and therefore often miss them:

  • Complexity appears late: Despite our best efforts to surface it during planning and design activities. This is the reason plans go awry at the eleventh hour and deadlines that seemed achievable are inexplicably missed;
  • Completeness is hard to nail: Specifically, deadline-completeness. This means only the things that are strictly necessary for a viable release, launch or demo at the deadline. This is likely smaller than the list you feel you want to include, but adds crucial items that are usually not visible to a client, such as productionising, releasing, legal formalities, etc. Many of these are usually slotted in just-in-time before a deadline, or missed. Denial of the need to nail completeness, or discovery of further complexity here, can undermine a deadline.

Maybe we could try something along the following lines, to hit deadlines more often:

  • Find the Essentials for Deadline-Completeness: Begin by ruthlessly separating the work that must be completed for the deadline, but perhaps in a heavily-downgraded form.
    This might mean something releasable to a production environment (in a walled-off manner, minus a final trivial “reveal” on the deadline date), something that discharges legalities, and something that exercises the agreed use cases in a minimal but viable manner.
    Encourage people to write separate stories for bare bones deadline completeness, and then the rest.
    Also write meta stories for items required for completeness that would otherwise be forgotten due to not being visible to a client, such as deployments and productionising;
  • Hit deadline-completeness early: Complete the bare bones deadline-sensitive work as early as possible, and nothing else. In an Agile approach, this should be at least a sprint or two before the deadline itself. You will end up with a very minimal but released (though perhaps walled-off) system that would hit your deadline, but would perhaps disappoint you in a number of ways. Learn to accept this, because you won’t be revealing this version of your work and something much more crucial just happened that is worth celebrating: You already hit the deadline. You are already capable of delivering. So now, you can…
  • Upgrade, iteratively: Add in the work to upgrade that initial complete solution in tight iterations. Each of these should result in a system that is “better” in some way but still deadline-complete; remains releasable, still discharges legal obligations, still exercises the same use cases and perhaps some new and less crucial ones.
    Iterate on these upgrades, in a order of decreasing priority, until the deadline.

When the deadline comes, as it inevitably will, you are guaranteed to hit it in some viable and complete manner. There will always be upgrades you wish you could have included but they will be the least important ones and, much more crucially, you aren’t left with an incomplete solution that can’t released, demonstrated or used.

Approaching deadlines in this way means that complexity can be handled as it arises, without derailing the deadline. Hitting deadline-completeness in a minimal way, then upgrading, allows complexity to push out less-crucial upgrades if necessary. Yes, you don’t want it to… but the reality is it might need to. Post-completeness, there is room for the battle between complexity and upgrades to take place, however that plays out and without risking the deadline.

How do you persuade people to adopt this approach? By showing them that everything is still planned to be included, but that deadline completeness is prized first. Assure them that other upgrades, in decreasing priority order, will only be omitted if unforeseen complexities or problems arise. The maximum value possible is still going to be delivered. Nothing has changed but the approach to delivery and risk.

Isn’t this just Agile? If your approach to Agile (and there are many) includes a notion of deadline completeness, perhaps. But who really does Agile that way? After hitting the deadline early, the iterations are Agile-like. But this approach forces early inclusion of aspects that might be unseen to a customer in an Agile world — hence no stories — but which are crucial for the deadline, such as productionising.

Find the essentials and complete them early, then upgrade. By planning in a way that handles complexity like this, maybe we can let it do its worst — as it inevitably will — and still deliver to a deadline?

Why Time as a Solopreneur Might Make You a Better Team Player

forwardTeamwork: Good. Lone work: Bad.

Or at least that’s how the stereotype drummed into us through education and our careers seems to go. We learn to focus our CVs and resumés on our team contributions, and to downplay the things we achieved entirely alone.

But what if the things we achieved on our own somehow made us more effective the next time we joined a team? What if a balance of both experiences made for better team players?

It’s my experience that teamwork between people who have never known an occasional lone accomplishment can suffer from a few blind spots: Such team members may have an inaccurate view of their contribution and how to tune it, having only ever seen their work as part of a larger deliverable. There’s a danger of feeling like a full four-wheel contributor, whilst actually running on three wheels and being unaware how much your contribution leans on the work of others. People who have never known personal wins can see a team project as their only chance to demonstrate their abilities, and may be over-invested in personal outcomes rather than team outcomes, safe in the knowledge that they can shine elsewhere or next time.

So what do I mean by lone accomplishments? Lone accomplishments could be a product (software, hardware, anything), a piece of art, training materials, blog posts, or a book. Anything you actually launch, publish or deliver to an audience, for which the entire deliverable depends on you, and for which you have no backup or other input to assist. Anything for which there is no scapegoat once you deliver it; it is yours, good and bad.

I’ve done this twice, with software products of my own. They were far from a commercial success, but the lessons learned were worth more than the time I spent and the salary I forfeited in those months. Since then, I’ve gone back to teamwork in startups, and really appreciated the perspective that my lone achievements have given me.

So what do lone accomplishers bring to a team? How can lone work strengthen and define you?

  • People with lone projects under their belt tend to have a more accurate view of their own strengths and weaknesses, and an appreciation for the roles others perform in a company.. because they’ve probably filled them at some point, albeit probably rather clumsily. Most former solopreneurs will have noticed how they couldn’t possibly fill all those roles alone… and will appreciate that it is only possible to cover them well in a team where a variety of skillsets are present.
    For me, as a software engineer, I now have a great appreciation of the other roles involved in startup life: Marketing, PR, design, QA, Ops, etc. Prior to undertaking my own projects, I probably had a dismissive or inaccurate view of those roles.
  • People with lone projects under their belt already have personal “wins” in the bag, so they don’t feel the need to act as if the next team project is their own pet project or chance to shine. This makes conversations more about a team win, rather than a personal win, less religious, more exploratory, and more practical.
  • People with lone projects under their belt tend to appreciate the difficulties of building something entirely alone, and therefore the need for others. The mature lesson from this is a willingness to delegate… and truly delegate, giving people a long leash and adjusting it appropriately. Knowing I can’t do it alone, but might be able to achieve it with others, makes me value the contribution of others and the need to delegate effectively.

Why is lone work a rarity? Aside from the widespread celebration of teamwork, we probably shy away from lone work because we know it will truly define or break us; there is no middle ground, and so we fear it. Through it, we will either discover, once and for all, that we can lean into a challenge on our own, or that we don’t (yet) have what it takes. Unlike teamwork, there is no scapegoat, no fallback, no-one else to blame. This is a hard reality to face.

But I’m convinced that every day we put off an attempt at lone work, is a day we never really understand what we are capable of; both alone, and in terms of our contribution to a team.

I’m convinced that, particularly in industries that involve building something (software, hardware, arts), we should exercise our lone capabilities on a regular basis, and at least once a year. It’s an ongoing eye opener on who we are, what we’re capable of, and therefore what we each bring to a team.

Far from being a red flag when hiring, lone work — when properly learned from — could be the thing that truly makes a strong team player.

Distil Complexity, Nail Theory, Build Software… Just Not All at Once

questionmark

Trying to pat your head whilst rubbing your stomach is the standard way to demonstrate that we, as humans, find it difficult to perform certain activities concurrently.

The software project equivalent is attempting to overlap activities that teams find it difficult to handle in combination. It’s just a reality that some things are hard enough on their own, and so we hamper our efforts if we attempt to combine them.

It’s been my experience that projects where there is at least an attempt to separate, as much as possible, the following activities are those that experience fewer hiccups. It may still be necessary to iterate through these activities regularly, and they are not waterfall-style one-offs, but being aware of the complexity of doing more than one of them at once can help to simplify things for teams and to ensure one flows into the other:

  • Distilling Domain Complexity – Every software product is built to deliver a solution in a unique problem domain. Often, there is much to clarify in this domain, and much complexity to unravel and distil. This can be something of a voyage of discovery, particularly if it takes a while to extract that knowledge from a domain expert and to figure out which aspects of it the project will require. As building products for a market can be like chasing a moving target, it is highly likely that this domain-related activity will be revisited many times during a project;
  • Nailing Academic Theory – Beyond well-worn Software Architecture and Computer Science principles, a project may rely upon deeper academic theory, such as Artificial Intelligence, Machine Learning, Big Data… or non-tech project-specific areas such as psychology, natural language, etc. Each of these alone are huge fields, full of theory. The problem is, you can’t build software with theory, and so we need to pin down practical forms of that theory that will be implemented in software. This may involve prototyping, comparative analysis of different approaches, and finally a choice between palatable options.
    There is a tendency to linger over these decisions, and an attractiveness in remaining in that land of possibilities. However, software engineering requires knowns, not possibilities, and the sooner theory is nailed down — for this project or iteration anyway, as we can always make different decisions next time — the better.
  • Building Software – Software engineering is concerned with building stable, scalable, understandable software to meet a need. There is sufficient difficulty in doing that in isolation, without overlapping with the previous activities. For large chunks of time, teams need to focus on building software, unencumbered by academic theory or domain ambiguities. It is almost an unwritten assumption on some projects that most of the difficulty lies in the previous two activities (problem domain and academic theory), and that building the resulting software solution will be comparatively easy or, at least, will be more of a known activity. However, the complexities and practicalities of building software require that teams focus on the activity where possible.

Although we may revisit each of these activities many times during a project, identifying and managing the boundaries between them helps to isolate them from one another. One great way to do that is by creating and maintaining great team documentation: Domain knowledge and concrete decisions based upon academic theory are perfect examples where documentation can form a neat output from one activity (albeit perhaps occasionally updated), to be consumed by another. Documentation needn’t be heavy and cumbersome and writing just enough, but before it is needed, should be encouraged.

I wonder, how many times that we’ve seen projects go awry could we identify examples of these activities bleeding into one another too much? And, where projects have gone comparatively smoothly, I’d be interested in hearing whether it was because these activities were understood to be complex in combination.

I guess it’s all part of improving the task of building complex software, with a human team.

Software Frameworks: Occasionally, Reject or Reinvent the Wheel

moonSoftware frameworks are everywhere, and rightly so: Spring, Grails, Angular, Knockout, Backbone… the list is endless.

In essence, a framework is an abstraction upon which we write our app-/product-specific code. We use them to enable reuse of well-worn functionality and, like all abstractions, to hide the implementation and underlying complexity.

Use of frameworks allows us to simplify and speed up development efforts. It’s rather a no-brainer, hence their proliferation.

But under what conditions would we choose not to use a framework or to write our own? Surely we’d just be reinventing the wheel? Perhaps, but just occasionally, maybe the wheel doesn’t fit or we need a better wheel.

Framework Fitness

To be used on a project, a framework must at least be:

  • Functional – It goes without saying that a framework must do what we need it to do; delivering the functionality we require. There must be a clear benefit in using it;
  • Configurable / Customisable – It must be possible configure or extend that functionality (via customisation or plugins), tailoring it to our specific needs, and perhaps even turn off portions of it if we don’t need them or if they are inappropriate;
  • Documented – There must be up-to-date documentation, to make the above possible. We mustn’t need to dig to discover how to use the framework;
  • Efficient – The framework must not introduce performance problems of its own. If there is a convenience in writing our app using a framework, that must not be paid for via a performance degradation we aren’t willing to accept.
    (Anyone who has seen the numerous levels in a Spring stack trace will know how intriguing it is to see just how much is going on behind the scenes, and will occasionally have wondered about the potential performance impact of it all);
  • Proven & Stable – Once we commit to a framework, we are essentially relying on it. The stability of our app / product is directly affected by the stability of the framework. If we want to deliver cast-iron stability to our end users, then we’d better use a framework that itself offers cast-iron stability! At the very least, a framework must have been proven to be robust in production, preferably by someone else, before we choose to launch a product with it;
  • Owned & Supported – If there are unforeseen problems, or bugs — and there are always bugs — it helps if the framework is supported either by a company or an active development community. It is no good waiting six months for a fix to a framework problem that can’t otherwise be worked around.

If a candidate framework is missing or weak in one or more of the above, we might need to look elsewhere or choose to develop the functionality we’re looking for ourselves, perhaps itself in the form of a framework for reuse elsewhere. The cost of ditching or switching frameworks if we don’t assess the suitability up-front can be significant.

Healthy Curiosity

Whether or not a particular frameworks suits our needs, I think there’s educational value in knowing at least a little about the technology that lies beneath that framework. Such knowledge of the foundations upon which it is based may help us to debug problems or, if appropriate, to invent a replacement for the framework ourselves.

Without knowledge of what the framework is doing, we won’t know whether it is doing any good. It is always worth having an idea of whether our own efforts would be better, if only to confirm that they wouldn’t be!

Healthy Skepticism

Blind use of frameworks because other similar projects are using them, or use of them on projects where we use a mere fragment or sliver of their functionality, should be discouraged. The risks probably outweigh the benefits. I think we always need to look at the upside of using a particular framework, specifically for this project.

 

In conclusion, frameworks are largely a huge benefit in software development, but only if we know why we’re using them, when we’re sure that they fit our purpose, and when we understand (at least at a high level) what they are doing beneath the hood.

Just occasionally, omission of the framework or use of own implementation may be a more sensible option. It’s worth remembering that.

The Best-Laid Plans of Task-Based Engineering

018-linkedinWhen faced with the challenge of building software of any considerable size, we rather sensibly tend to begin by breaking down the complexity and fleshing out a design or architecture. Then we break down the work involved in building that design into tasks or user “stories”.

Sometimes we group stories into wider “epics”, themes or stages, but generally we estimate, schedule, and conduct the work of building software at a task level: Tasks are what we assign, place on agile boards, and discuss our progress in terms of.

(I’ll refer to everything as “tasks” from here on, but I also mean user stories, and much of what I’m referring to also applies to bug fixes and other ticketed items)

Tasks are abstractions of the underlying engineering work required, and a task-based view of engineering makes the process of building complex software more understandable, manageable and distributable as a team. But it also tends to ignore certain truths about software complexity, tasks themselves and the ways we actually work on them, both on our own and together in teams. In-particular, the tools we currently use to manage task-based engineering are rather restrictive and cumbersome.

So, given that it seems we need task-based engineering, what is it about the way we approach it, and current task-based tools, that can hamper our efforts?

Tasks Abstract Away Complexity

A task is simply an abstraction of the work involved in building a software feature, a use case, a component or maybe just of fixing a bug. As with all abstractions, it necessarily hides detail that, for all but the simplest of tasks, may be discovered later when we actually work on it, despite our best efforts at planning time.

Sometimes, as the true complexity of the work involved in a task becomes clear, we realise that we should restructure the task to break it into more manageable chunks, and that sub-tasks should ideally replace some (but perhaps not all) of the original parent task. This discovery of structure and complexity may occur several times, to an arbitrary depth, and perhaps only after part of the original task has already been completed. We may even discover aspects of the original design, and the tasks slated to build it, are wrong.

Rather than implying poor planning, this is simply a part of the discovery process and the complexity inherent in building software, particularly in an agile manner where we’re trying not to pre-think too much up-front. We need to accommodate that inevitable change, reflect it in the tasks we are working on and in those slated for the future.

Most current task management tools aren’t great at letting us change anything more than very small numbers of tasks and task-based planning. They certainly don’t help us to visualise the results we end up with. In a sense, they leave us with quite brittle and sizeable task-based plans. With some persistence though, it is usually possible to reflect the required changes, though this may require time that isn’t available and we risk the task-based view drifting away from the engineering reality.

What can also be particularly tough with current tools is arbitrarily defining sub-tasks to any depth, as we discover complexity and break down a piece of work further. We may need to have parent and child tasks representing slightly overlapping and part-completed functionality, whilst being able to see estimates for all of that work. I’m not sure that current tools allow much of this without significant discipline in our use of them. In this sense, they are too brittle to allow us to reflect the engineering reality beyond our (now outdated) initial plan.

Tasks Need Surrounding Context

Our planning process envisioned the whole (a delivery, a completed system, or a bunch of features for a sprint), then broke it down into tasks. Quite often, rather a bewilderingly large number of them. The tasks somehow lose our view of the whole, and it is hard to determine whether those tasks, collectively, still make up a meaningful delivery or omit anything crucial.

It seems like we need to retain some visualisation or record of the structure by which we arrived at the individual tasks, so we can work backwards from the tasks to the whole. Even when working on an individual task, we often need to get enough surrounding context to work on it, as each task rarely describes that in sufficient detail.

Being able to see where tasks fit into the bigger picture is particularly necessary when our plan inevitably changes over time, to avoid us getting lost in a changing sea of tasks, the intended outcome of which we can no-longer visualise clearly.

Current task management tools don’t allow us to retain the more complex structure of groups of tasks. We are limited to “epics”, tags, simple sub-tasks and basic categorisation. We need better ways of visualising how the tasks fit together to form the whole that we’re working towards, allowing us to spot omissions and to track progress. After all, the collective structure of the tasks will probably be as complex as the structure of the overall system we’re building.

Tasks Need Collaboration (Sometimes)

No-matter how much we break them down, often a task requires unexpected collaboration with someone else (together, or a hand off then a hand back), integration with their work or reaching an agreement. That micro-collaboration is hard to model, but crucial to a task’s completion, though we often assume (perhaps hope?) it is irrelevant.

Whether or not one person “owns” the task and the responsibility for its completion, several people may need to do work on it and must find time in their workload. This is particularly true with user stories, as we don’t tend to break them down into chunks any smaller than a story we can define in business / product terms.

Current task management tools suggest a single assignee per task, or multiple assignees but with no record of individual effort required or how the collaboration will occur. We actually need to reflect a more complex sense of ownership and collaboration, even if most of the work will be done by one person with fleeting collaboration at some point. Failing to capture this in a basic form can be a cause of tasks being unexpectedly “blocked” during sprints, or the logical next steps towards their completion being unclear.

Tasks Have Dependencies (Sometimes)

Sometimes, a task depends on other tasks being completed (or part-completed), or a bunch of tasks need to happen in a certain logical order. Often a task that is scheduled to be completed this week or this sprint is blocked by an implied dependency that won’t be resolved anytime soon. We must model dependencies, or risk impacting our progress if we discover them late, or if many tasks get blocked on a key resource that we should have planned around earlier.

Current task management tools can model dependencies clumsily at the task level, but aren’t good at helping us to visualise them. This can often be another cause of tasks being blocked during sprints. They certainly aren’t good at modelling dependencies between groups of tasks, and we tend to have to visualise those ourselves: e.g. All tasks in Stage 2 depend on the tasks in Stage 1.

A visual representation of dependencies at a task and group level, and ability to move them around, would give us a more efficient view on how best to approach those tasks in a sensible order.

Task Completion Often Isn’t Clean

Often a task is almost completed, with a small piece of work to be finished, perhaps when unblocked by another person or after a dependency or decision is resolved. The inability to easily mark the task as partially complete, or to define the remaining work (perhaps in a sub-task), hampers visibility of the true state of the task, particularly on agile boards.

Creating a new sub-task can be cumbersome, and it needs adding into the plan or sprint, in correct relation to the original task, so it isn’t forgotten or confusing when seen in isolation. Often the administrative effort leads to us just leaving the original task open until the remaining work is completed.

Current task management tools assume task completion is clean and atomic, leading to tasks remaining “in progress” when they are often 90% complete and the tool should allow us to easily reflect that. This often hampers visibility of remaining work, particularly close to the end of a sprint.

So What?

Clearly, I’m pointing out some broad problems with simplistic views of task-based engineering here and suggesting some very general solutions. Not all of these problems will apply to a project but, particularly with larger teams, I’ve seen many of them and their impact is real. Some teams tackle these problems well as part of the way they work, but others clearly struggle with the realities of task-based engineering.

A quick summary:

  • Tasks are valuable abstractions for understanding and managing engineering complexity, but the methods and tools we currently use to manage them are rather rigid. We need to be able to visualise and change large numbers of tasks easily, see their overall status and visualise how they combine to form a planned delivery or feature;
  • We need to be able to break tasks down to any level, describe what overlaps and what’s already complete, so we can model our fluid discovery of complexity but retain an ability to estimate and gauge the remaining effort involved. Again, current tools and methods are too brittle;
  • We need to be able to model and visualise task and task group dependencies, where they matter (they don’t always), or even just record that entire swathes of tasks must take place in a certain loose order. Current tools make this too cumbersome;
  • We need to model the necessary collaboration within individual tasks, both simple and more complex, so we can be aware of it. Current tools are too cumbersome to make this effective or even worth the effort, and agile boards are too simplistic.
  • Most crucially… All of this must remain light, easy to visualise and easy to change. Current approaches and tools are way too cumbersome, and often work against us.

As they say, “Your mileage may vary”. So I’d be really interested in hearing how this ties into your own views of task-based software engineering, whether you encounter any of these (or other) problems, and if you think the kind of broad changes I’m suggesting might improve things.

One thing is certain: Task-based engineering is here to stay!

Kaizen, Innovation and the Entrepreneurial Life

10251565_830162623679537_14497031_nKaizen is a Japanese word meaning “good change”, but it has also been the basis of an approach to “continual improvement” that has been applied in many industries and as a way to drive personal change.

The idea is that incredibly small changes, made continually and consistently, tend to beat radical plans, proposals and initiatives because they work with, rather than against, human nature. Small changes bypass the brain’s tendency to fear and resist change. They also set us up to actually like the change and to want to accelerate it naturally.

It struck me recently that many of the words applied to startups and entrepreneurial pursuits are the polar opposites of Kaizen: They tend to imply “disruption” and sweeping changes carried through by radical innovations, actions and energy. But does this expectation of brave change on a huge level put our entrepreneurial dreams at odds with human nature? Are we hampering our own efforts by working against, rather than with, our brains?

What if, instead of trying to find one radical way to “disrupt” an industry, we tried to notice small things that are true about that industry, make small changes to improve those things, and to use that momentum to gradually see the bigger possibilities? What if we tried to notice small ways in which we could improve someone’s life with a product or service, and build on that? What if we tried to innovate by making a small but meaningful change to an existing product or technology and see that as the basis for a bigger change?

And when it comes down to ourselves, as entrepreneurs… What if, rather than trying to affect the various changes in character, lifestyle and approach required to become entrepreneurial overnight — as if a butterfly-like metamorphosis in human behaviour is even possible — we tried to make small changes to our thinking, attitudes and behaviour to become more entrepreneurial over time? Kaizen techniques for personal change highlight the benefits of ludicrously small changes at first, to beat resistance. Those changes tend to snowball into genuine change driven by the subtle rewiring of our brains caused by adopting the smaller changes. There is certainly less chance of us reverting to our old behaviours if we affect change gradually, and it tends to be longer-lasting.

Of-course, all this talk of small changes goes against the grain of an entrepreneurial world where we value disruption and innovation. But what if, rather than distracting us, making these small changes increased the chances that we’d actually spot the bigger and more radical possibilities? It’s certainly easier to see what’s possible when you’re moving in the right direction, rather than standing still waiting for inspiration to strike.

In our quest for disruption, bigger and better, maybe we could do with realising that small and continuous change could be the most effective way there, albeit perhaps rather a counterintuitive one.

(Image: (c) 2014, Ian Cackett)