My experience coming from C++ to JavaScript

Having been with C++ for a long time, I’d become comfortable with it. I’d use it both as a scripting language and for building complex desktop applications. Adding Qt gave me powerful tools for creating user interfaces; and I had access to OpenCL for accelerated computing, OpenGL for real-time graphics, OpenCV for image processing, etc. For my needs, this ecosystem worked very well for a long time.

But over time, pressure mounted for me to expand into the web development sphere. So I started learning JavaScript.

In this post, I’ll go over some of the experiences I had coming from C++ to JavaScript, including some of the things that went well and some that didn’t. I’ll try to give a few pointers to people who’re planning to do the same, and hopefully some perspectives to JavaScript developers who might be interested in C++.

First impressions

I had some prior familiarity with HTML and CSS from using them to style Qt components and from dabbling in simple web pages, but I’d never done anything with JavaScript. By this time the language was a couple decades old; the specification was up to about ES9.

JavaScript’s syntax is very similar to C++, to the point that the differences feel dialectal. You get your familiar statements like if, for, and switch; you define functions much the same way (just with dynamic typing); and especially if you’ve written C++ in a procedural style, your program flow may be very similar.

But although the syntactic similarity can ease the transitioning from one language to the other, it’s in some ways a hinderance: things can appear familiar but end up working in an unexpected way, quickly landing you in one of the pitfalls of JavaScript.

The initial pitfalls

There were three notable pitfalls I got to experience when getting started with JavaScript:

1. Behavior of array indices
2. Deep vs. shallow copies
3. The ‘this’ keyword

They all had to do with what on the syntactic level looked like familiar concepts from C++ but in practice turned out to work quite differently.

Behavior of array indices

On the surface, indexing arrays works the same way in C++ and JavaScript: given an array array, you can access its elements with array[0...n]. And this indeed holds true if you only use (positive) integers for the array index. But as soon as you do something like array[x / 2], you’ll run into divergent behavior.

In C++, the result of x / 2 – where x is an integer – is an integer. When you write array[3 / 2], you’ll be getting array[1], and you’re probably very used to it being this way.

In JavaScript, different rules apply. First, the language has no integers, only floating-point numbers. Second, array indices are converted into strings. That means 3 / 2 produces the floating-point value 1.5, which means array[3 / 2] gives you array["1.5"], which in turn will equal undefined in the likely case that the array has no element with the key “1.5”.

For example, in C++:

const std::array array = {10, 11, 12};
// array[1] == 11
// array[3 / 2] == array[1] == 11

In JavaScript:

const array = [10, 11, 12];
// array[1] === array["1"] === 11
// array[3 / 2] === array["1.5"] === undefined (oops)

This isn’t a big problem at the end of the day because you can coax the index value into an integer (e.g. array[Math.floor(3 / 2)] === array["1"]). However, unlike a C++ compiler, a JavaScript engine probably won’t warn you about using a floating-point value as an array index, so until you notice it manually, you’ll get a silent NaN propagating in your program from what at first glance looks to be well-behaved code.

Read more about arrays in JavaScript here.

Deep vs. shallow copies

In C++, I had gotten used to being able to deeply copy plain structs with direct assignment:

struct pod_structure
{
    int array[3];
};

pod_structure object = {10, 11, 12};

// This copies by value, i.e. makes a deep copy.
pod_structure objectCopy = object;

// Since the copy is deep, modifying it doesn't modify the original.
objectCopy.array[0] = 99;
// object.array[0] == 10
// objectCopy.array[0] == 99

This didn’t translate well to JavaScript, where objects are copied by reference:

function data_structure(array) {
    return {
        array: [...array]
    }
};

const object = data_structure([10, 11, 12]);

// This copies by reference, i.e. makes a shallow copy.
const objectCopy = object;

// The copy is shallow, so modifying it modifies the original.
objectCopy.array[0] = 99;
// object.array[0] === 99
// objectCopy.array[0] === 99

I remember being somewhat stunned when I first ported a piece of C++ code to JavaScript and saw that making a deep copy of a plain data structure was actually a bit of a rabbit’s hole. Direct assignment typically but not always copies by reference (JavaScript makes no syntactic distinction between data and reference, so you’ll need to know the spec), certain methods like Object.assign() create copies that are partially deep and partially shallow, and semi-official deep-copying kludges like objectCopy = JSON.parse(JSON.stringify(object)) also have their pitfalls (e.g. JSON.stringify() will silently omit JSON-incompatible data).

One way to get around this issue – a way I ended up favoring – is to use immutable objects, so that you don’t need to care whether a copy is a reference. If you want to modify an object, you create a new immutable object with those modifications, and references to the original object remain as they were. The downside is that this isn’t fully straightforward to accomplish either – you could use the standard Object.freeze() method to make an object immutable, but since it doesn’t freeze nested objects, you’d have to go an extra mile to ensure true immutability down the whole property tree.

(As of late 2021, although the landscape of deep copying in JavaScript remains somewhat messy, support for a standard structuredClone() method has begun to land in browsers.)

The ‘this’ keyword

C++ and JavaScript both provide a this keyword, and in both languages it represents a reference to a particular context. But the mechanics of it can differ in painful ways.

In C++, this evaluates to a pointer that refers to an instance of the class (or struct) in which it’s used:

struct object
{
    object* self()
    {
        return this;
    }
};

object instance;
// instance.self() == &instance == 0x...

// Can't use 'this' outside of a class context.
std::cout << this;
// Compiler: ^~~~ error: invalid use of 'this' in non-member function

In JavaScript, this refers to an execution context and has a much broader domain both functionally and in what values it can represent:

function say_this() {
    console.log(this);
}

const object = {
    initial_this: this,
    say_this: function(){console.log(this)},
    say_this_arrow: ()=>console.log(this)
};

console.log(this);
// "Window {...}"

console.log(object.initial_this);
// "Window {...}"

object.say_this();
// "{initial_this: Window, say_this: f, ...}"

object.say_this_arrow();
// "Window {...}"

say_this();
// "undefined" (in strict mode) or "Window {...}"

new say_this();
// "say_this {}"

say_this.call(document.head);
// "<head>...</head>"

The this of C++ is semantically telling you, “this instance of the class”. The this of JavaScript likewise appears to say, “this context that I’m in”, but means to say, “this branch of execution”, which in turn depends on factors that aren’t visible in the local semantic context. So if you use this inside an object in JavaScript, you might expect it to refer to the object itself, but in reality it may refer to (a) the object, (b) nothing, or (c) anything, depending on how the object is being accessed. For this reason, especially if you’re used to how it works in C++, it’s very easy to mess up this in JavaScript.

I’d recommend ignoring what you know about C++ in this regard and even to avoid using JavaScript’s this altogether until you’re sure you understand what it would do – and why so – in the particular situation you’d use it in. Otherwise it’s too easy to be creating fragile, hard to understand code.

Read more about JavaScript’s this keyword here.

Time to refactor?

After a while of building things with JavaScript, I’d become settled into certain patterns, some of which I later felt best to move away from and some that I chose to keep. Among those patterns have been:

1. C++-isms
2. Compensating for the lack of static typing
3. Easing into the messy package ecosystem

C++-isms

One of the things I most often have found myself refactoring in my early JavaScript code are its in-code interfaces. Often they’ve had a contextually unpleasant C++ tinge to them; they’ve felt clunky or out of place in JavaScript.

For example, since C++ doesn’t allow named function arguments, you only declare paremeter names in the function signature and then call the function without re-declaring the names:

int sum(const std::vector<int> &numbers = {}, const int initialValue = 0)
{
    // ...
}

sum({1, 2, 3}, 5);

I’d port code like that to JavaScript almost verbatim:

function sum(numbers = [], initialValue = 0) {
    // ...
}

sum([1, 2, 3], 5);

The result isn’t outright bad, but in neither case does the call to sum() tell the reader what the arguments mean. The person could assume that the list of values provides the numbers to be summed, and maybe by convention that 5 is the sum’s initial value. But they’d need to look up the function signature to be sure.

By finagling with JavaScript’s syntax (in this case, object destructuring) you can have named arguments:

function sum({numbers = [], initialValue = 0} = {}) {
    // ...
}

sum({numbers: [1, 2, 3], initialValue: 5});

I think the call to sum() now looks and feels more like JavaScript. Even if you disagree or prefer the C++-like way, you’ll probably agree that the C++-style call is more obscure about intent. Besides being more explicit, the destructured version is more flexible to call: you can re-arrange the arguments, and default value initialization doesn’t require a certain argument order either.

Compensating for the lack of static typing

I’d been in the habit of using assertions in C++ to ensure – among other things – the validity of arguments passed to functions. Since JavaScript doesn’t support static typing like C++ does, my asserting extended naturally to checking arguments’ types as well. Something like this:

function func(arg) {
    console.assert(typeof arg == "number", "'arg' must be of type 'number'");
}

Sometimes I’d feel I was being overly pedantic writing type checks in a language made to be dynamically typed. Not to mention each assertion took up more lines of code, required more time to write, and needed to be maintained when the intended type of an argument was changed. Maybe it was an anti-pattern?

Well, I’ve so far decided not to refactor away assertions from my JavaScript code. In fact, I still keep adding them to new code. Consider the following:

function func(arg) {
    console.assert(typeof arg == "number", "'arg' must be of type 'number'");
}

const array = [1, 2, 3];

func(array[1]);
// Runs OK (arg === 2, which is fine)

func(array[1 / 2]);
// Assertion failure (arg === undefined, the array has no key "0.5")

func("1");
// Assertion failure (arg is not a number by strict comparison)

The second call to func() makes the mistake of assuming that integer division in JavaScript results in an integer. The assertion immediately catches the mistake.

The third call to func() is OK in the sense that the function could probably implicitly cast the string into a number and then execute correctly. But still, the function expects a number, so its receiving a string indicates that some other part of the codebase is misbehaving (maybe it’s passing along a stringified number directly from a network response). In my opinion it’s probably better for the long-term reliability of the application that you’re alerted to this.

That said, these assertions are just a roundabout way of shoehorning in a kind of static typing. A more elegant way might be to use TypeScript, which provides an additional syntax layer over JavaScript that includes native-like static types. With TypeScript, we could leave out the manual type assertions and let the TypeScript compiler handle type checking:

// The argument is now of a TypeScript-specific 'number' type.
function func(arg: number) {}

const array = [1, 2, 3];

func(array[1]);
// No errors from TypeScript (the call is OK)

func(array[1 / 2]);
// No errors from TypeScript (but the index bug goes undetected)

func("1");
// TypeScript error: Argument of type 'string' is not assignable to parameter of type 'number'

I’ve used TypeScript for only a short while, but so far my impressions of it are mixed. Introducing static typing can increase the reliability and readability of your code, and TypeScript’s interface system may get you to think about and define your in-code interfaces more clearly. On the other hand, its type system doesn’t always feel solidly integrated with JavaScript, and from what I’ve seen it can add considerable complexity and/or compatibility issues to your build process.

Easing into the messy package ecosystem

Among the biggest elephants in the room has to be JavaScript’s sprawling package ecosystem.

As a C++ developer, I was used to working at low level, carefully managing the dependencies of my applications and often introducing no dependencies at all besides the standard library. By contrast, JavaScript is a high-level language where a typical project may depend on hundreds or thousands of external packages, and whose developer base seems more accepting of abstracting away the lower-level details behind those external dependencies.

When learning React, it’s typically recommended to use the create-react-app project bootstrapper. It sets up a React development environment in an automated way, saving you the trouble of manually doing the boilerplate. The downside is that it also makes your development environment dependent on over 1,500 extra packages.

When I started learning React (I was still fairly new to JavaScript overall), I thought the amount dependencies introduced by create-react-app was absolutely nuts. Why would a hello-world app need hundreds of miscellaneous dependencies? I chose to go against the grain of every React tutorial and learn it without packages or package managers:

<div id="react-container"></div>
<script src="react.development.js"></script>
<script src="react-dom.development.js"></script>
<script>
    const container = document.getElementById("react-container");
    const component = React.createElement("span", {}, "Hello world");
    ReactDOM.render(component, container);
</script>

In this vein, there are no extra packages required, and I didn’t even need to install a package manager. I could build full React apps this way, and they’d be lighter-weight and potentially more secure (or not). But I’d also be missing out on quality-of-life improvements like…

// Creating a nested element with plain React.
divWithChild =
    React.createElement("div", {},
        React.createElement("span", {className: "label"}, "Hello world")
    );

// Creating the same element with JSX syntax (dependent on a transpiler).
divWithChild = (
    <div>
        <span className="label">
            Hello world
        </span>
    </div>
);

…not to mention I’d perpetually be working uphill and against the grain, because create-react-app and the like make things much easier, and most fellow JavaScript developers will be of that opinion.

I think easing into the apparent craziness of the JavaScript package ecosystem was the hardest part about transitioning from C++ to JavaScript. It meant no longer understanding certain aspects of my programs at lower levels. On the other hand, I wasn’t supposed to be working at low level with a high-level language to begin with, and I could be more productive by accepting that.

Future outlook

In my opinion, having first learnt C++ can give you an edge in becoming proficient in JavaScript. C++ offers a lot of freedom but requires a lot of responsibility; it motivates you to try to write well-behaving code because the alternative is a compromised application (or worse). If the motivation to build reliable code carries into JavaScript, it can elevate your work above some of the quirks of the language that might otherwise negatively affect the quality of your work – or at least you might get bitten by those quirks less often.

But experience of C++ can also be major baggage. You might be used to having lower-level control over your programs – for instance, insisting that dependencies be kept to a minimum. In the higher-level JavaScript this may become an anti-pattern that holds you back from being as effective of a developer as you could be.

I personally still use both languages. C++ gives me high performance, syntactic power, and few restrictions. JavaScript gives me first-class networking, a huge platform to distribute on, and a powerful GUI system in the triad of HTML5/CSS3/JavaScript; it can be an expressive, creative language and I often have fun using it.

Working at Druid, according to Druids

In the spring of 2021, we asked our people how they feel about working at Druid, what they value in work, and how they see themselves and their co-workers. Here comes a summary of the answers. Hopefully this will give you an idea of what it’s like to work with us.

Most of the Druids, over 70%, work with software development, the rest with something else such as sales or project management. So in general we can say that Druid is a very developer-oriented company packed with deep knowledge of software development. People really enjoy problem solving and finding solutions.

How is work and management at Druid?

We have a lot of long-term employees a low turnover. Why is that? What makes people stay? Not surprisingly, the answer lies in our culture. Freedom and flexibility, a relaxed atmosphere with nice and helpful co-workers, interesting projects and opportunities – for us, these are the ingredients that make up an attractive workplace. This may sound clichéd, since so many companies are advocating these things nowadays, but our greatest strength is our culture, which actively nurtures these values.

Quite logically, our people consider company culture to be the most important factor at work, along with flexible working hours. Other important factors for us are professional development, the possibility to work remotely, our team and colleagues, and the impact of our work – doing work that matters.

Druid is a self-organized company and we are exploring the Teal philosophy. In practice this means that we have a high level of autonomy and we are accountable for coordinating work with each other. Decisions affecting the whole company are made in swarms that anyone can join or set up. Currently we have over 10 active swarms ranging from tech to strategy, from billing to recruitment. Outside the swarms, any individual can make a decision to fix an issue or complete a task by first seeking advice from others.

What are we Druids like?

We describe ourselves and our co-workers as relaxed and easy-going, skilled and talented people who are passionate about what they do. It also seems that we have two types of people at Druid: those who want to focus purely on coding and don’t want to be disturbed, and those who want to be involved in developing the company and really value Teal and what it represents. And both are totally ok.

Druids have a wide range of hobbies and personal interests. The most popular free time activities seem to be making and listening to music, gaming and coding as well as spending time with family and friends. And the list goes on. We have people who are into art, baking, cars, carpentry, climbing, cooking, fishing, hiking, gym and sports in general, Japanese culture and martial arts, motorcycling, movies, travelling, reading, sailing, walking and yoga.

When we go deep into what really matters in life, our people value honesty and integrity, freedom, fairness, equality, and family. These are the values that unite all of us Druids as human beings.

Edit: Our CTO Marko would like to add that ice hockey belongs to our hobby list as well 😀

If you feel that you can relate to these thoughts and could see yourself working with us, don’t hesitate to get in touch. We are always interested in getting to know new colleagues!

Read more about working with us on our careers page

Battling developer shortage with educational cooperation

Without today’s juniors there wouldn’t be tomorrow’s seniors. This very much holds true within any specialist field, but it still feels like the truth about healthy workforce structure has been forgotten in today’s knowledge work.

As a company that cooperates a lot with public sector organizations, it must be said that sometimes it’s exceedingly difficult to get newcomers to the software development field actually hired into projects. Project teams are picked based on CVs in close fought competitive tendering with winning bids invariably going to teams made up of 10 year veterans with black belts in coding. You can’t get beginners hired to gather valuable experience even if their fees were next to nothing.

The board of the Code from Finland association, lead by their chairman Janne Kalliola, laudably pointed out in their opinion piece in Helsingin Sanomat that strict competitive tendering criteria are exacerbating the developer shortage and are holding back the growth of the industry.

Even though experience is valuable and valued, the programming industry needs new skilled workers now more than ever. The way we are trying to affect the industry is through educational cooperation and by hiring junior software developers ourselves.

Cooperation with the Helsinki Business College

A versatile content management system like Drupal, which is aimed at large clients, requires a constant source of experts. Fresh software developers are often enthusiastic open source contributors, and their careers will benefit from Drupal’s large international community. Being an active open source developer could well act as a stepping stone to an international career in programming.

In Finland, Drupal programming education is offered by our longstanding partner, the Helsinki Business College. Our collaboration during the years has been varied: we’ve taught in their courses, coached teachers in the use of Drupal, organized company visits and taken in interns whenever possible. When things work out, we are happy to offer permanent jobs to the interns. Many HBC students have graduated to working life through us.

In January of 2022 we will take the next step in our collaboration as we become the cooperation partner for the React & Drupal Full Stack Web Developer study program at HBC. We want to take active part in familiarizing students with the everyday life within the software industry, as well as the Drupal community and naturally with us as a company.

As a partner we will help HBC to specify the practice project carried out during the studies, and I will work as the project’s product owner for the development teams. At the end of the study period we hope to snag as many skilled developers as possible as interns, which will hopefully lead to them becoming gainfully employed developers in the industry.

Maintenance work provides all-round experience

Even though the public sector’s attitude towards novice developers is hardly enthusiastic, competitive tendering shenanigans won’t be the end of anyone’s career. The comprehensive maintenance and small scale development services we offer are of key importance when it comes to getting junior coders employed. Most of our interns will find themselves under the care of our Magical Support team and will later be employed as part of the team.

We at Druid don’t consider the maintenance services we provide as a necessary evil but rather a significant source of our revenue. Over 95% of our clients move to maintenance at the end of an implementation project, and the amount of work done under the maintenance contract is often manifold compared to the original project.

Our multilingual and multi-skilled team is responsible for ensuring that our clients’ websites remain functional, secure, and up-to-date in terms of features. The technical skills required in these tasks range from the comprehensive knowledge of large Drupal systems to creating modern JavaScript and React code. Is there a better place for a newcomer to the industry to get a feel of the diversity of working life?

We at Druid have helped bring to life a number of success stories whose main star has been a motivated fledgling software developer. Those are the stories we yearn for. That’s why we want to offer a solid stepping stone to working life to as many people as possible.

8 things we learned at Druid

Last week we said goodbye to our wonderful interns Florence and Bea. During their four month internship with us, they built a demo application with JavaScript for car repair shops and their customers – and did an absolutely brilliant job.

The app lets users choose the nearest car repair shop, book an appointment for car maintenance, keep in touch with the shop through in-app chat and see the progress stage of their car as it’s being repaired. The app was built with the user in mind, focusing on the user’s convenience.

Before Bea and Florence embarked on new adventures, we asked them to write about their learnings and experiences from the project and beyond. It turned out they had a lot to share – so let’s dive right in!

1. Progressive Web Apps (PWA)

PWAs have been in the app ecosystem for some time and you may have probably used one without knowing. They are web apps with an enhanced capability in modern web browsers.

Among many of the features we discovered are its installability, offline mode experience, linkability, native-app feel, re-engaging nature and a single codebase that can be used on different devices. It was interesting to know that companies like Uber, Trivago, AliExpress, Spotify, Starbucks and Pinterest are already using PWAs as their web service platform.

Although it was a new concept for us, a lot of research enlightened us on how we could apply it in the project we wanted to build. We built a PWA with Create React App (CRA) which was incredibly convenient because CRA has a template for building PWAs.

2. Teamwork

Team synergy was by far one of the most important factors that influenced the outcome of our project. This encompasses a lot of factors ranging from setting project expectations to good and clear communication.

We tried as much as possible to be on the same page in the building process of the project. From the technical perspective, we set up a system where we could review each other’s codes before merging changes to our main branch. That meant we had to ensure we were writing readable and understandable codes. In order to ensure uniformity in our codebase, we had rules set in ESLINT.

After working independently to solve complex problems for more than half-way into the internship, we decided to try pair coding at some point. To be honest, we wished we had started with pair coding much earlier, because we realised how knowledge sharing contributed to arriving at solutions quickly.

3. Who needs a server these days?

You may have heard about “serverless backend”, which means running your server-side code without having to maintain your own server. The solution is tempting, because it cuts the costs (on-demand, so you don’t pay for idle time of the server), it’s easy to scale and lowers administrative overhead.

AWS Lambda is a popular choice, but managing service discovery, API gateways, and keeping your app and the functions in sync can be overwhelming – that’s where Netlify functions come to the rescue. We chose to use them in our project, because they are a make-it-easier layer over Lambda functions, which means we could use them without an AWS account; also, keeping everything up to date was a breeze.

With the serverless functions in a correctly named folder in the project, we were deploying our React frontend together with the serverless backend at the same time and Netlify did the dirty work handling all the rest. Add to that the continuous deployment straight from our GitHub repository, including previews of pull requests updates, and you got yourself a recipe for painless deployment handling!

4. Mercure for real-time features

For our app we needed real-time communication to create our in-app chat and to update the UI of the end user when the admin changes the state of the user’s appointment. We decided to use Mercure, an open protocol not using Web Sockets, but instead built on top of HTTP and SSE (Server-Sent Events).

With the Mercure Hub set up (using Docker image for local development and deployed to Druid’s server for production), we needed to do two things in our app: publish updates and subscribe to them.

Publishing happens when someone sends a new chat message or the admin changes the appointment state – a regular POST request is sent from our frontend to the serverless backend, where the data is saved to the database and Mercure update is published to the Hub.

Then the Hub’s job is to pass this update down the correct channels, so that only the users subscribed to it get the information. Subscribers are browsers; for example when an end user opens their appointment view, the app subscribes to updates about their appointment (change of stage or price estimate) and to updates of their chat (and only theirs, so that they don’t get somebody else’s messages by mistake).

To subscribe, we used EventSource, which is kind of a keep-alive connection to the server (the Mercure Hub in our case) and differs from Web Sockets in that EventSource is one-way communication, it can only listen to updates, not send any – which is all we needed.

5. Web push notifications

Like any new feature that was implemented without prior knowledge of how it should work, implementing push notification was mostly learning by doing. Push notifications are messages sent to user’s devices from a website via a browser. And with the offline feature of PWAs, users do not miss notifications even when they are not online.

Looking at our app’s use case, push notification capabilities were useful for notifying users whenever there was a change in information. For eCommerce and marketers it’s an amazing way to re-engage with web visitors whenever there are new products, releases, etc. It was relevant to build this feature, especially as PWAs are becoming more popular and being supported by more browsers.

6. User experience

We needed to keep the end user in mind as we worked on our app. Have you noticed the unexpected shifting of elements like videos, buttons or fonts on a web page while the page is still loading? Exactly, that can cause a poor user experience and is referred to as Cumulative Layout Shift (CLS). It’s a Google metric which is used to measure the user’s experience on a web page.

CLS is usually a good way to detect coding issues which could be resolved to improve usability on your site. These may be tiny details that could slip through during development and may seem “irrelevant”, but they definitely count! What is the point in building an app that lacks usability? Knowing about CLS and its importance highlighted user experience as an important skill to have as it makes us better developers.

7. Scrummy Scrum

Agile methodologies have become the default way of working in the software development field, so to nobody’s surprise we used the Scrum method in our project. We learnt about this style at school, but only working on a long-term project unveils the true power of Scrum.

Thanks to the regular feedback sessions in retrospective meetings, with every iteration there were less conflicts or misunderstandings, with every sprint we worked better and more efficiently. For every ticket in the backlog we assigned points to estimate the time and effort needed to complete the task, which helped us understand deeper the goals, expectations and each other’s views.

We also made mistakes like not deploying every sprint – it came back to bite us in the last few weeks of the project as we ended up with several issues accumulated in production. Debugging and understanding which error is caused by which part of the code failing was unnecessarily complicated, so lesson learnt!

8. Teal is the new black

There’s so much more in the management philosophies landscape than the traditional, hierarchical way of big bosses, small bosses and the workers. Druid is slowly but steadily undergoing a Teal transformation, aiming at a flatter management structure.

Many tasks at the company are being taken care of by swarms – a group of people interested in the issue or topic around which the swarm was formed. The doers declare their readiness to put time and effort into the subject, the helpers can offer a little less time, and the followers are interested in the works, but for one reason or another can’t promise much help.

In our time at Druid we had a chance to observe among other things the work of the salary week swarm who took care of designing and executing salary negotiations. The best thing about swarms is they can be formed as issues or tasks arise, and torn down when they solve what they were born to do or when they become inactive and die out.

Another part of the Teal way that we found interesting is the advice process helping in decision making. When there is a decision to be made, one person volunteers to be the decision maker and asks for advice, especially from people directly affected by the decision and from experts on the topic. Others can then give advice (not their opinion, but strictly advice), but the final choice of course of action is made by the decision-maker – that also includes full responsibility for the outcome.