Recently in a project, I stumbled into an interesting puzzle and decided to share it with you along with my own solution. Part of the credit goes to Jarkko Hyöty for great feedback and ideas.
We needed a data model where exactly two persons could have a partnership with each other during some time period, while one person should never belong to more than one partnership simultaneously. Initially, the problem sounded quite simple, but it starts to get a little more tricky as you dive deeper into it – especially if you want to model those rules as database constraints. It might make sense to model this sort of a thing rather in a graph database, but we wanted to stick with the good old PostgreSQL which we were already using.

First steps towards the solution

So how might we start to model this in a relational database? My first idea for modelling this kind of one-to-two relationship was something like this:

    id              SERIAL PRIMARY KEY, -- auto-incrementing integer
    name            TEXT NOT NULL
    -- other person details ...
CREATE TABLE partnership (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v1(),
    person1         INTEGER REFERENCES person(id) ON DELETE CASCADE,
    person2         INTEGER REFERENCES person(id) ON DELETE CASCADE,
    start_date      DATE NOT NULL,
    end_date        DATE NOT NULL CHECK (start_date <= end_date)

That does perfectly limit the number of partners in a partnership to exactly two. However, there is a troublesome distinction between person 1 and person 2. The roles in the partnership are not strictly equal. So maybe something like this instead?

CREATE TABLE partnership (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v1(),
    start_date      DATE NOT NULL,
    end_date        DATE NOT NULL CHECK (start_date <= end_date)
CREATE TABLE partner (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v1(),
    partnership_id  UUID REFERENCES partnership(id) ON DELETE CASCADE,
    person_id       INTEGER REFERENCES person(id) ON DELETE CASCADE

Limiting the maximum number of partners

Now we no longer distinguish between partners 1 and 2, so that is good, but since this is now a standard one-to-many relationship, it no longer covers the requirement of there being exactly two people in a partnership. That requirement can be divided into two parts: 1) a partnership must have at least two members, and 2) a partnership must have at most two members. The first one is actually quite difficult, so let’s return to it later. The second one, however, can be solved for example like this:

CREATE TABLE partnership (
    id              UUID PRIMARY KEY DEFAULT uuid_generate_v1(),
    start_date      DATE NOT NULL,
    end_date        DATE NOT NULL CHECK (start_date <= end_date)
CREATE TABLE partner (
    partnership_id  UUID REFERENCES partnership(id) ON DELETE CASCADE,
    ind             SMALLINT NOT NULL CHECK (ind BETWEEN 1 AND 2),
    person_id       INTEGER REFERENCES person(id) ON DELETE CASCADE,
    PRIMARY KEY (partnership_id, ind),
    UNIQUE (partnership_id, person_id)

Here we have removed the separate primary key id from the partner table and instead added a composite primary key of partnership_id and ind. Here ind (i.e. index) is a new integer column, where the value must equal either 1 or 2. Because it is used in the composite key, it cannot have the same value twice within a partnership. Therefore it enforces the constraint that there can be at most two people in a partnership. Finally, we also add a unique constraint for (partnership_id, person_id) to prevent one person from being in a partnership with him/herself, although we will soon be adding another constraint which effectively also does prevent this.

Preventing overlapping partnerships

What about the requirement of no overlapping partnerships then? At first, it sounded impossible to enforce this on the database constraint level, but after some research, I found out that the PostgreSQL exclude constraint combined with a date range and an overlap operator might be a potential fit for this. For example, in this presentation by Jeff Davis, those were used to guarantee that there are no overlapping reservations for the same room. However, applying it to our current data model does not seem to quite work out. This kind of constraint can only compare rows within one table, but we have person_id and dates in different tables. Could we somehow still make it work?
Let’s try changing our data model a bit more by moving the date columns from the partnership association table into the same partner table with person_id. At this point the partnership table has no other columns left except for the primary key id. Therefore it is actually redundant and can be left out if we just generate the shared partnership_id at the application level instead.

CREATE TABLE partner (
    partnership_id  UUID NOT NULL,
    ind             SMALLINT NOT NULL CHECK (ind BETWEEN 1 AND 2),
    person_id       INTEGER REFERENCES person(id) ON DELETE CASCADE,
    start_date      DATE NOT NULL,
    end_date        DATE NOT NULL CHECK (start_date <= end_date),
    PRIMARY KEY (partnership_id, ind),
    UNIQUE (partnership_id, person_id)

Since all the relevant data is now located at the same table, it becomes possible to add an exclusion constraint which prevents one person from having two simultaneous partnerships. The idea we want to express in the constraint is that if any two rows have the same person_id and their durations overlap, then that is a constraint violation. The syntax for that is this:

    person_id WITH =,
    daterange(start_date, end_date, '[]') WITH &&

Note that this uses a gist index so you need to have the btree_gist extension enabled.


As you may have noticed while changing the data model we simultaneously created a new problem though. Since the dates are no longer shared through the association table, it is now possible for the two members of a partnership to have different durations for it. This does not really make sense here. Fortunately, that can be remedied by adding a couple more exclusion constraints which will cause a constraint violation if two rows with equal partnership_id values have differing start_date or end_date values. Note that when updating dates of an existing partnership, this constraint will temporarily break until the second row has also been updated, so we must make these constraints deferred to only enforce them at transaction commit time.


Limiting the minimum number of partners

Finally, let’s return to the constraint that a valid partnership should always have two persons in it – not just one. As far as I know, this can only be solved by a trigger function which checks the partnership member count on insert, update and delete, and raises an exception if the constraint is violated. Furthermore, it has to be a deferred trigger, so that the rule is only enforced at transaction commit time, instead of raising an error immediately when you try to insert the first person to the partnership before you even have had a chance to insert the second person.
This kind of triggers can cause a considerable amount of complexity and may be difficult to maintain and debug, so in the end, we decided that enforcing this constraint is best left to the application code since it is anyway trivial to do there.

Testing out the solution

So does our finished data model now make sense and is it usable? Let’s draft a couple of queries to validate that!
Creating a new partnership can be done by inserting two rows having same partnership_id, start_date and end_date with each other and different ind and .

-- Assuming we have two persons in the person table with ids 1 and 2:
-- INSERT INTO person (name) VALUES ('Donald'), ('Daisy');
        '336a7c66-a43c-478d-a724-a65b377d77ee',     -- some generated partnership_id
        1,                                          -- first ind
        1,                                          -- first person_id
        '2018-01-01',                               -- start_date
        '2019-06-30'                                -- end_date
        '336a7c66-a43c-478d-a724-a65b377d77ee',     -- same partnership_id
        2,                                          -- second ind
        2,                                          -- second person_id
        '2018-01-01',                               -- same start_date
        '2019-06-30'                                -- same end_date

Fetching partners for a given person is slightly more complex, but not too bad either. We just need to fetch all rows where there exists another row with the same partnership_id and the desired person_id. So to get for example Donald’s partners we could write:

Fetching Donald’s partners
SELECT person_id, name, start_date, end_date
FROM partner p1                                         -- Select from partner table
LEFT OUTER JOIN person ON = p1.person_id      -- (joined with the person table just to get the partner's name too)
WHERE EXISTS (                                          -- all the rows for which there exists
    SELECT 1 FROM partner p2                            -- another partner row
    WHERE p2.person_id = 1 AND                          -- where the person is Donald (id 1)
          p2.partnership_id = p1.partnership_id AND     -- which is part of the same partnership
          p2.ind <> p1.ind                                -- but is not the same row

Resulting in


Updating a partnership duration can also be done with just one simple statement, even though the dates must be updated on both rows. Note also, that in order to keep the time comparisons simple we did not make end_date nullable, but we can use a postgreSQL special value ‘infinity’ if we want to express that a partnership currently has no known end date. That value can later be converted into null at the application level if desired.

UPDATE partner
SET start_date = '2018-02-10', end_date = 'infinity'
WHERE partnership_id = '336a7c66-a43c-478d-a724-a65b377d77ee';

All in all the solution seems to work fine, even though one can question if it would have made more sense to just check all the constraints in the application level to keep the data model simpler. Anyway, if you have alternative solutions for this little puzzle I’ll be interested in hearing them. Cheers!

Joosa Kurvinen

Joosa is an experienced fullstack software developer with a very broad skill set. He is always eager to learn and try out new things, regardless of whether that is with backend, frontend, devops or architecture. He has an agile mindset and always strives after clean and testable code. Joosa graduated from the University of Helsinki and wrote his master's thesis on AI and optimization algorithms.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Syksyn podcast-sarjan toisessa jaksossa puhutaan tunteista ja niiden tärkeydestä yritysten menestystekijänä. Vieraakseni sain Camilla Tuomisen, joka aloitti tunteista puhumisen yrityksissä silloin, kun sitä pidettiin vielä ’vaaleanpunaisena höttönä’. Camillan kanssa keskustelimme tunnetaitojen merkityksestä työn tuloksissa ja työtekijäkokemuksessa.
Kuuntele podcast tai lue artikkeli alta:

Innovointikyky tarvitsee tunteita

Camilla on tehnyt viimeiset seitsemän vuotta töitä yrityksissä tunteiden tunnistamisen ja johtamisen parissa. ”Enää tunteista ei puhuta vaaleanpunaisena höttönä. Tunteiden merkitys ja arvostus on jatkuvassa nousussa.”
Johtajat arvostavat työntekijöidensä innovointikykyä ja valmiutta heitellä villejäkin ideoita. ”Psykologisesti turvallisessa ympäristössä syntyy kahjoimmat ideat, joiden seassa voi piillä seuraava menestystarina.”
Troijan hevoseksi tunteiden merkityksen kasvussa Camilla nimeää tekoälyn: Tulevaisuuden tutkijat ja ajattelijat ovat yhtä mieltä siitä, että tekoälyn opettamisessa tarvitaan nyt inhimillistä puolta enemmän kuin koskaan. Sosiaalisen kanssakäymisen säännöt tai hiljaisten signaalien lukeminen ovat sellaista osaamista, johon tarvitaan meitä ihmisiä. Tunteilla on tässä työssä tärkeä rooli.

Sekä-että: rationaalista ja empaattista

Camilla korostaa sitä, että vaikka tunteista puhutaan, ei meidän pitäisi puhua pelkästään niistä. ”Faktojen tuoma rationaalinen informaatio on edelleen tärkeää, ja parhaimmillaan osaamme yhdistää faktan ja tunteet analyyttisesti.”
Johtamisessa on pitkään puhuttu kovista ja pehmeistä osa-alueista, ja tunteet ovat liittyneet näistä kaikkein pehmeimpiin. Tällainen jaottelu käy kuitenkin vanhanaikaiseksi, kun osaava työvoima on monen asiantuntijaorganisaation kovin kilpailuvaltti.

Työn muutos vaatii pääkopasta huolehtimista

Muutos maataloudesta tehtaisiin ja sittemmin toimistoihin on muuttanut sitä, mistä elementeistä työ koostuu. Tietotyössä, joka on täynnä kilpailevia viestejä ja piippaavia keskeytyksiä, meillä on paine pitää huolta omasta hyvinvoinnistamme ja jaksamisesta. ”Jos emme osaa johtaa omaa päätämme ja hallita stressiä, sillä on valtavat vaikutukset kognitiivisiin kykyihin.” Lopulta ne samat kyvyt tai niiden puute heijastuvat yrityksen tuloksellisuuteen ja jokaisen omaan terveyteen.

Tunteita voi oppia lukemaan

Tunteiden kieltä voi oppia lukemaan ja ymmärtämään. Lapset ja nuoret saavat tunnetaitojen opetusta päiväkodeissa ja kouluissa. Myös työelämässä voitaisiin harjoitella näitä taitoja:
”Tiukoissa tilanteissa olisi hyötyä siitä, että tiedän, miten rauhoitan itseni tai ymmärrän, mitä tunteet koittavat minulle kertoa.”
”Jos tunteita turrutetaan, ollaan jatkuvasti sellaisessa seiskan-kasin maailmassa, joka on ’ihan jees’. Mutta kuka meistä sitten haluaa tyytyä sellaiseen?”
Uupumus ja kovat odotukset omasta suoriutumisesta ovat arkipäivää monille. Hallinnan tunne työpäivän aikana on yksi tärkeimmistä taidoista tulevaisuuden työelämässä. Myös tässä tarvitsemme ymmärrystä omista kognitiivisista kyvyistämme.

Tunteet muutosjohtamisen työkaluna?

On tutkittuakin tietoa, että muutos menee meillä helposti tunteisiin. Vaikka me kaikki tiedämme tämän omasta kokemuksestamme, on muutoksen johtaminen ja läpivieminen usein hyvin rationaalista. Johtamisessa maltetaan keskittyä tunteisiin vain harvoin. Camillan mukaan suora puhe tunnereaktioista olisi tervetullutta organisaatioiden muutoshankkeissa. Tunteista puhumisen positiivisista vaikutuksista on myös tieteellistä näyttöä: ”Kun ihmiset pystyvät nimeämään tunteet, niin myllerrystä kokeneet aivoalueet rauhoittuvat ja olo paranee.”
Tunteiden pullottaminen ei ole hyvästä, mutta toisaalta tunteissa vellominen ja niihin jumiin jääminen ei sekään palvele tarkoitusta. ”Tunteiden tarkoitus on, että ne tuovat meille energiaa ja informaatiota. Ne yrittävät kertoa meille jotain käsillä olevasta tilanteesta.” Jos siis jätämme tunteet narikkaan, tärkeää tietoa jää hyödyntämättä.

Tunteissa ei ole exceliä – siksi johtajan on syytä aloittaa itsestään

Sosiaalinen kanssakäyminen, luovuus ja intuitio ovat kaikki tulevaisuuden taitoja mm. World Economic Forumin mukaan. Niitä yhdistää tunteiden tapaan hähmäisyys, joka ei sovi exceliin. Siitä huolimatta kaikkia näitä taitoja voidaan opetella. Luottamusta, pelkojen tunnistamista ja epävarmuuden sietämistä ruokitaan johdon esimerkillä.
Tiedetään myös, että tunteet tarttuvat ja monia tunteita koetaan kollektiivisesti. Tunneilmaisua kaivataan työpaikoille, mutta entä jos joukossa on ’tunnejyrä’ – henkilö, jota muut väistelevät tai myötäilevät? ”Vaikka tunteiden ilmaisu on tärkeää, ei mikä tahansa käytös ole töissä sopivaa. Vihaisuus ja huutaminen on useimmiten merkki pelosta.”

Tunteista jokaisen sisäinen kompassi

Puhutaan paljon intuition kuuntelemisesta ja omien tunteiden tiedostamisesta. Miten jokainen meistä voi hyötyä siitä? Alun perin tunteet ovat auttaneet ihmistä selviytymään. Ne ovat kertoneet esimerkiksi uhista ja vaaroista. ”Mahanpohjassamme on edelleen eräänlainen tietokone, joka kertoo meille tietoa ja ohjeita. Tunteet yrittävät saada meitä kulkemaan jotain kohti ja poispäin jostakin. Jos tietty tilanne kertoo joka kerta meille saman viestin, olisi tunteita syytä kuunnella.”

Tunteiden tunnistamisen ja hyödyntämisen positiiviset vaikutukset?

Kun sallimme työpaikalla tunteet ja rohkenemme puhua niistä, tilan valtaa helpotus. Ilmapiiri muuttuu, kun yksilöt ja heidän erilaiset persoonallisuuden piirteensä ja perspektiivinsä osataan huomioida.

Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle? Tutustu julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Eeva Kiiskinen

Eeva toimii organisaatiomuotoilun ja muutosjohtamisen asiantuntijana. Hän sparraa asiakkaita organisoitumiseen, vuorovaikutukseen ja asiakaskeskeiseen kulttuuriin liittyvissä projekteissa. Eeva toimii johtamisviestinnän kouluttajana Tampereen yliopiston EMBA-koulutuksissa. Eevan tuotantotalouden alan väitöskirja käsitteli johtajuuden rakentumista strategisessa muutostilanteessa.

Linkedin profileTwitter profile

Piditkö lukemastasi? Jaa se myös muille.

Double the money, triple the fun?

I’m Minna Vänskä, a service designer at Gofore. I’ve been working in the tech world now for 21 years. By training, I’m a Master of Arts. Earlier in this blog series Jaana told how she focused on mathematics instead of English. Funnily enough, now I’m working with Jaana side by side for the same customer at Gofore and I did study English as my main subject at the university. 🙂 Other studies included information studies (earlier library science), journalism and mass media, multimedia and audio-visual culture. And now that I look back on it, it’s a pretty perfect combo together with the years of experience in IT and added with some studies in service design.

While growing up I remember wanting to be a queen or an archaeologist. I was telling (lecturing) people everything I knew about king Tut at the age of 8. Then, of course, everyone wanted to be a ’lakasukoneenkuljettaja’, basically driving a Zamboni, or ice resurfacer to be exact. I’ve always liked to make stuff: To create a doll out of a used shampoo bottle, to paint and do renovations. The kind of problem-solving that I like is to construct and sew a winter jacket or cut and build a stained-glass lamp from scratch.

Being part of a product building machine

At the age of 22 I got a summer job at Nokia, I did my thesis there and got paid for it, something that is still too rare in the Arts faculties. By the time I was 25 I had graduated and was busy writing the user guide for the first-ever Symbian OS phone. At Nokia I got to work with amazingly talented, world-class specialists, experts, and product builders, I learned about mobile technologies, customer care, logistics, factory setup, design for sustainability, and package design to name a few. And I think we were among the first to try out the legal design. I got enthusiastic about user research, observing people in context, about analytics and visual communication. I still think that one of my greatest career achievements has been the Visual user guide for the emerging markets: innovating and creating something new, a visual user guide, serving millions of customers better with a deliverable that cost 0.01€, it saved money and the environment.

I’ve always worked in a male-dominant workplace with an 80/20, or even 90/10 ratio and if you weren’t technically trained or “an engineer” you really were the odd one out. We used to joke about the elevators at Nokia, if a man didn’t crush you at the doors, he must be a lawyer. Being from an arts background didn’t make me a lesser employee for the company though. I remember the HR being brilliant at the time. If someone was able to get the work done and stand the scheduling pressures, they wanted to keep you. And no, not everyone could stand the pressure or be able to handle the complexity of 5 simultaneous product programs and their 200+ different SW variants and that didn’t have anything to do with gender or training.

Systemic problems cannot be solved in silos

I had heard about service design already when working at Nokia and saw it as a solution to the many systemic problems that I had seen. I strongly believe that multi-disciplinary teams working towards a shared goal of customer success is the most efficient way for organisations to a) invent new solutions and b) fix customer issues. However, organisational structures are often preventing this, teams are incentivised wrongly and rarely are decisions made based on data.
Currently, at Gofore I’m responsible for user needs studies, design sprints, innovation, concepting and service design. I like to arrange multi-disciplinary workshops, involve users by applying service design methods.  My eyes shine in the moments when I see teams gathered around a customer journey or customer problem and working hard together to fix it. What I currently want to focus even more on are:

  • AI and robotics combined with the understanding of human behaviour
  • helping companies to be more knowledge lead with the help of analytics and data visualisation
  • building services that bridge the digital and physical realms and, for example, use drama exercises in testing these out

Equal support for your career

My career in tech has taken me to a London park for a morning run, to Texas, Georgia, Poland, Italy, Belgium, and Lapland. Early on I realised that a career in tech would be a much better provider than many of the possible careers in arts. Being a teacher or a librarian would’ve meant maybe half of the salary. But there’s no glory unless you’re enjoying it all. For me having a partner to balance the load has been essential. It’s not easy having small kids and mom off to London semi-regularly.

I’m a third generation of women with a university degree. But things are not always progressing for the better. My granny had 5 kids and worked in industry as an economist. But unlike many mommies nowadays she didn’t even try to shine in every area of life. In the 1950’s she had both a housekeeper and a nanny to help her. And in the summer kids were sent to the “farm” out of the way. Today, women try to be perfect on all fronts of life. For me, it’s been a life long path to finding balance, deciding what I like to focus on, what I value most, where I enjoy being and not worry about the rest so much.

Keep at it

I was listening to the keynote talks from Charity Wanjiku of Strauss Energy Ltd. and Laura Tirkkonen-Rajasalo of Sulapac at the WiT event on Friday and the experiences felt similar. Don’t mind what society is telling you your role or path should be like, you can do it. Perseverance or ‘sisu” is key and 99% of achievement is showing up every day and doing the work. Also, don’t shy away from new opportunities, it’s OK to be scared and by practice, you can overcome your fears.
My motto is from Virkkukoukkunen:

Lentäminen on asennekysymys – To fly is all about the attitude.

Read the previous parts of this blog series here:
Passion for continuous improvement
A love for mathematics led the way
Subconscious career design
Value your skills – they are needed in tech
My career in tech – a continuous learning curve
Finding my own material to design
Working as a woman in tech

Minna Vänskä

Minna on kokenut kansainvälisten, monialaista yhteistyötä vaativien konseptointi- ja kehitysprojektien vetäjä, kuluttajatutkimuksen ja viestinnän asiantuntija. Goforella hänen vastuullaan ovat asiakastutkimukset, käyttökokemuksen suunnittelu, konseptointi- ja palvelumuotoiluprojektit. Minnan sydäntä lähellä on asiakkaiden ja henkilökunnan osallistaminen uusien palveluiden kehittämistyöhön, työpajojen järjestäminen sekä palvelumuotoilumetodien soveltaminen asiakastutkimuksessa.

Piditkö lukemastasi? Jaa se myös muille.

This blog series is split into four parts:

  1. General information of secrets management
  2. Example how to store secrets into a version control
  3. Example how to use encrypted secrets in CI-pipelines
  4. Security issue and threat analysis based on previous examples

I’ll provide a small threat and security issue analysis based on this blog post series and the examples used, case-by-case.

Compromised personal or service account cloud credentials

It is possible that some member’s or service account’s credentials are compromised one way or another.
Simple steps for protecting compromised accounts:

  • Revoke and reissue credentials
  • Regenerate API keys
  • Look logs for unauthorised access and usage
  • Remove unexpected resources on a cloud platform

At least the Google Cloud Platform (GCP) has its own detailed guide for compromised credentials which can be read here:
Last but not least: always use the multi-factor authentication for personal credentials.

Reducing vulnerability to a key compromise

If an attacker gets access to the key and encrypted secrets then all the secrets can be exposed – well, game over. The attacker can take your skeletons from version control and use them to carry out harmful acts like exposing IP addresses, passwords, API keys or even something worse.
However, you can reduce vulnerability to a key compromise with a few simple things.

Don’t re-use keys too often

With proper secrets management, you should never use a single, ”one-and-only”, key for encrypting and decrypting all the secrets you have. You should create a new key which has its own purpose and encryption and is only for specific data.
In this blog series, I’ve used only one key to demonstrate how Mozilla SOPS work. You could make environment or version control repository based keys which would make things harder for an attacker. In the Very secret development operations, part II: Storing skeletons into a version control -blog, there was an example of how multiple different keys can be used with environment-specific rules (Advanced usage – Creation rules configuration).

Rotate keys and remove old versions of a key

Key rotation is a simple method to prevent key compromise: the old version of the key is versioned to history and a new, primary version of the key is created. Only the primary key is used for encrypting (and decrypting) the secrets while the old versions of key are used only for decrypting the secrets. Still, an attacker can have an old version of the key and use that for data leakage – but not for long if you remove old versions of the key!
You can manually or automatically rotate or destroy keys in cloud platforms. GCP has multiple guides regarding key management like:

In the Very secret development operations, part III: CI-pipelines -blog, there was an example of how to setup rotation period for a key, so GCP rotates keys automatically.
With SOPS you can renew the data key from the secret by command:

sops -r test.enc.yaml

For further reading about key rotation with SOPS:

A person leaving the project/organisation

If a person is leaving a company or a project they can be a sort of security issue if they still have access to resources after they have left. You have to always revoke access to all systems and keys which they have used.
While SOPS handles access to keys automatically, you only have to revoke access to cloud platforms and servers where your keys are stored. GCP has a good guide for revoking access to different resources:
Also, remember to revoke access to version control – like remove a member from a Gitlab group or project.

What could happen after a compromise?

As I mentioned earlier, an attacker could use a compromised key to make harmful acts like exposing IP addresses and passwords. But things can be even worse than that, so I’ll mention a few aspects.

  • Loss of sensitive information
    • Personal data
    • Industry secrets
    • IP addresses
  • Financial losses
    • Illegitimate financial transactions
    • Fines
    • Compensation to customers
  • Loss of reputation
    • Customer
    • Professional
    • Business

After all, your business can close down pretty quickly after the security breach. So keep your skeletons well hidden and secure secrets with proper secrets management, follow common security practices and follow, or even create security policies for your business and project.

Further reading:

Jarkko Koistinaho

Jarkko toimii Goforella teknisenä projektipäällikkönä ja hän on laatu- ja testausorientoitunut ohjelmistoalan ammattilainen. Testauksen lisäksi hän voi astua kehittäjän saappaisiin, Scrum Masteriksi tai tehdä järjestelmäasiantuntijalle tyypillisiä tehtäviä. Mallipohjainen testaus ja suorituskykytestaus ovat Jarkon erityisosaamisalueita.

Piditkö lukemastasi? Jaa se myös muille.

Jos johtajana tai organisaation kehittäjänä tavoitteenasi on kasvattaa tulevaisuuden kilpailukykyä ja haluat luoda organisaatiostasi edelläkävijän, aloita työ pohtimalla tätä kysymystä: Mikä on oma ihmiskäsitykseni? Ja kun vastaus on selvillä, miten se näkyy toiminnassani?
Douglas McGregorin tunnetun Theory X, Theory Y -teorian mukaan johtajan oletus yksilön motivaatiosta nojaa perustavanlaatuisesti joko luottamukseen tai epäluottamukseen. Perinteisesti organisaatiot on rakennettu kontrollin pohjalle ja Theory X:n mukaiselle ihmiskäsitykselle siitä, että ilman valvontaa ihmiset pyrkivät välttelemään vastuuta ja siksi heitä on ohjattava tiukasti kohti organisaation tavoitteita. Kontrolli lisää varmuutta, mutta valitettavasti häviää joustavuudessa.
Theory Y sen sijaan uskoo yksilön sisäsyntyiseen kiinnostukseen kehittyä työssään ja kantaa siitä vastuuta sekä kykyyn hyödyntää luovia ongelmanratkaisutaitojaan organisaation eduksi.

Kilpailukykyä luottamuksen avulla

Luottamus vähentää kontrollin tarvetta ja vapauttaa aikaa rutiineilta kasvua tuovalle tekemiselle. Se mahdollistaa kevyemmät rakenteet, skaalautuvuuden, avoimen vuorovaikutuksen, yhdessä kehittämisen – sekä nopeammat reaktiot markkinassa tapahtuviin liikkeisiin. Kiihtyvällä vauhdilla muuttuvassa kompleksisessa ympäristössä organisaation olemassaolo voi olla kiinni sen kyvystä muuttaa nopeasti suuntaa.
Yksilön näkökulmasta luottamus mahdollistaa vaikuttamisen omaan työhön ja lisää arvostuksen tunnetta sekä työn merkityksellisyyden kokemusta. Nämä taas tukevat korkeaa motivaatiota.

Onko yksilö luottamuksen arvoinen

Ajattelun muutos ja vanhasta poisoppiminen ovat vaikeimpia tehtäviämme. Koko elämän aikana kehittynyt uskomus siitä, voiko toisiin ihmisiin luottaa, vaatii syvää henkilökohtaista pohdiskelua, keskusteluja ja oivalluksia.
Uusi ajattelu, uudet toimintatavat ja johtamisteoriat haastavatkin erityisesti johtajan ja muut organisaatioiden kehittäjät – myös niin, että samalla oma rooli muuttuu päättäjästä valmentajaksi ja mahdollistajaksi.

Onnistumiset kannustavat kokeilemaan

Luottamukseen perustuvia yrityksiä ja organisaatioita yhdistäviä piirteitä ovat muun muassa läpinäkyvyys ja matala hierarkia, yhteisöllisyys, joustavuus sekä tasavertaisuus. Ja hyvä taloudellinen menestys.
Onnistuneita esimerkkejä löytyy jo ja uskomme, että tämän päivän kompleksisessa ympäristössä joustavuus päihittää kontrollin ja sen seurauksena luottamukseen perustuvat organisaatiot yleistyvät. Oppivan organisaation opein: voimme kokeilla, vaikka emme tiedä ja osaa kaikkea, vielä.

Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle? Tutustu julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Mari Wuoti

Mari on ihmis- ja asiakaslähtöinen organisaatioiden, johtamisen ja työkulttuurin uudistamisen asiantuntija. Digitalisaation luoma nopeasti ja jatkuvasti muuttuva, kompleksinen maailma kaipaa meiltä kaikilta perinteisten mallien haastamista. Nopeat kokeilut tarjoavat onnistumisia ja tuloksia pitkäjänteisen ja jatkuvan kulttuurin kehittämisen rinnalla. Marilla on vahva kokemus myös rekrytoinnista ja työnantajakuvan kehittämisestä, joista hän on ollut vastaamassa Goforella. Vuodesta 2018 Mari on toiminut valmentavana konsulttina oivalluttaen asiakkaita kehittämään uudistumiskykyään modernin johtamisen, itseohjautuvuuden ja ketterien kokeiluiden avulla.

Piditkö lukemastasi? Jaa se myös muille.

Haluatko ymmärtää paremmin asiakkaittesi ja markkinoittesi moninaisuutta? Oletko kyllästynyt eri lähteistä tuleviin faktoihin tai pitkiin ja uuvuttaviin keskiarvoistaviin tilastokäppyröihin? Olisiko nyt aika siirtyä erilaiset asiakasryhmät tunnistavaan, mutta kokonaisvaltaiseen ja asiakasdataa älykkäästi hyödyntävän vaikuttavan johtamisen aikaan?

Tämä onnistuu tilannekuvan, eli tiettyä ilmiötä kokonaisvaltaisesti kuvaavan laskennallisen ja tietopohjaisen datamallin avulla. Sen avulla päästään eroon sitkeästi organisaatioihin pesiytyneestä tavasta tehdä toisiinsa vaikuttavia päätöksiä niiden yhteisvaikutuksista tietämättä.
Asiakasdatan uudenlaisella yhdistelyllä tehtävät tilannekuvamallinnukset ovat tekoälyn hyödyntämisen yksi helpoimmin hyödynnettävistä alueista. Yksiulotteisten tai keskiarvoistavien mittareiden sijaan edistyneen analytiikan menetelmät mahdollistavat kohderyhmien tai ilmiöiden sisäisten dynamiikkojen tunnistamisen datan luokittelumenetelmien avulla.
Tilannekuva-analyysi on energisoivaa kaikille, sillä se tarjoaa jokaiselle tilannekuvakeskustelun osallistujalle datapohjaisen tarkastelun lähtökohdan, jota osallistujat täydentävät omilla näkemyksillään ja synnyttävät yhdessä ymmärrystä asiakaskunnan tilanteesta. Perinteinen analytiikka tarjoaa kylmiä lopputuloksia, mutta edistyneen analytiikan avulla tilannekuvan tuottamisen prosessissa tekoäly toimii tukiälynä. Tämän lisäksi se mahdollistaa asiantuntijaryhmän muodostamaan merkitystä heillä olevan hiljaisen tiedon avulla dialogin kautta.
Laskennalliset tulokset on mahdollista toteuttaa kevyesti ilman raskaita tietojärjestelmävaatimuksia ja tutkimusresursseja, joten se sopii hyvin myös pienille organisaatioille. Tilannekuvamalleja on helppo luoda toistuvasti kerran kehitetyn algoritmin avulla.
Asiakaskuntaan tai kohderyhmään liittyvät tilannekuvat mahdollistavat asiakaslähtöisen toimintakulttuurin synnyttämisen. Asiakasnäkymä voidaan tuoda nopeasti ja vähällä vaivalla kaikkien nähtäville. Nopeasti muuttuvassa toimintaympäristössä tilannekuvan hallinta on organisaatioille jatkuva elinehto. Kysynnän määrää, laatua ja kehittymistä on voitava seurata ja ennakoida päivä- tai viikkotasolla.
Useimmille organisaatioille jo ensimmäisen tilannekuvan näkeminen on pysäyttävä kokemus. Utuisesti hahmotettu asiakaskunta saa yhtäkkiä selkeitä piirteitä ja hahmoja, ja erilaiset kohderyhmät tunnistetaan uudella tavalla sekä heidän tarpeitaan pystytään arvioimaan jo hyvinkin alustavienkin tulosten pohjalta.

Mitkä ovat todennäköiset tulevaisuudet?

Moni olisi varmasti halukas tietämään, mitä tapahtuu tulevaisuudessa. Kristallipallo tilannekuva ei ole, mutta yhdistämällä siihen edistynyttä analytiikkaa ja systeemidynamiikkaa voidaan kyllä tehdä ennusteita siitä, mitkä ovat todennäköisiä tulevaisuuksia.
Tällöin esimerkiksi resurssien käytön suunnitteluun tai investointeihin saadaan aivan uudenlainen twisti.
Kun tuodaan markkinalle tuotteita tai pohditaan julkisten palveluiden tuottamisen palvelukapasiteettia ja -mitoitusta, päätöksiä ei tarvitse enää tehdä näppituntumalla tai peräpeiliin vilkuilemalla. Ne voidaan tehdä ennakoivien tilannekuvien avulla.
Tilannekuvia voidaan alkaa synnyttää matalalla kynnyksellä, esimerkiksi mallintamalla ilmiöitä tai tekemällä monipuolisia kyselyitä. Näitä voidaan asteittain rikastaa tiedolla ja näkemyksillä.
Olennaista on yhteistyö ja liikkeelle lähteminen. Yhteiseen tavoiteasetantaan, agendaan ja yhteisjohtamiseen opitaan vain sen tarjoamat hyödyt kokemalla – luomalla yhdessä ensimmäinen malli ja ensimmäinen kuva. Kukaan ei tiedä, mitä tuleman pitää. Tuntemattomat haasteet ratkaistaan kokeilemalla ja oppimalla.

Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle? Tutustu julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Petri Takala

Petri toimii Goforella johdon neuvonantajana digitaalisen liiketoiminnan ja analytiikan avulla johtamisen asiantuntijana. Hänellä on laaja kokemus kompleksisten johtamistilanteiden tukemisessa analytiikan avulla erilaisissa tilanteissa, useilla sektoreilla ja organisaatioiden eri tasoilla.

Linkedin profileTwitter profile

Piditkö lukemastasi? Jaa se myös muille.

Digitalization is helping organizations and individuals build and expand their networks which leads to meaningful cooperation. Increasingly these networks are sharing time, insights and information and co-creating new business models and services. Business rules are in such constant change that regulators are struggling to keep up. To be resilient and stay relevant in this networked world, organizations need to constantly innovate new meaningful ways to communicate, interact and form relations with different participants. This does not happen from inside the company.

Understanding the wider scope, systems, value streams and relationships and how they work is a key element in driving innovations in this networked world. Many organizations claim to be customer centric however if you ask their customers the answer might be quite different. Customer surveys or ‘Happy or Not’ buttons at checkouts might give a quick impression of the organisation’s concern but this can be a false impression. Truly customer centric organizations curiously explore their customers’ holistic experiences in their world and changing contexts. To understand these, design methods such as observation techniques and contextual participatory methods are required.

The same can be said for understanding employees within the organisation. Employees know best what happens at the intersections with the external network participants they work with. Companies should never outsource their eyes and ears. Innovations do not flourish in an environment that does not listen to both their internal and external network participants.

Making the shift from company centric to customer and network-centric

Value in co-creation needs to be mutually beneficial whether it is monetary, experiential, environmental or societal. Meaningful innovations require a radical mindset shift in organizations – from company centric to customer centric and all the way to network centric. To drive innovations that are meaningful to different participants, real network centric organizations build their innovations around experiences. They try to understand people’s activities, practices and experiences in their world and in a context that extends beyond the organisation’s products and services. That is only possible when understanding individual behaviour and that isn’t easy.

People might be end-users, citizens, consumers, customers, employees, clients, partners or contributors and you need to observe them and listen to their stories, find out what is important to them in their world and in changing contexts, and find out why.

Are you company-centric or network-centric?

Using Design Thinking to facilitate constant change

Organizations that fearlessly withstand uncertainty and trust non-linear and iterative innovation processes driven by people-centric data have an advantage. The Design Thinking approach drives valuable innovations that are new to a specific context and time, creating value for all collaborative participants in a meaningful way. Innovations ultimately always need to be aligned with actual network participants’ unsatisfied and important jobs, pains and gains if they are going to be successful. This means that if an organisation`s innovation intent is not people driven, but technology and business driven, those innovations need to be validated with evidence that people really care about the innovation intent.

The powerful mindsets of design thinking guide the whole organization to break down silos and build an open, transparent and trust-building atmosphere that supports collaboration and the sharing of information and knowledge. This helps to cultivate an innovation culture that embraces the experiences of employees and external network participants.

The world in which we are living, and the future may seem foggy, but when you go out and observe the world with an open mind and with empathy, everything becomes clearer. The future does not just arrive – it is co-created within networks.

Uskotko sinä muutokseen? Siihen, että voit muuttaa maailmaa paremmaksi ihmisille ja ympäristölle? Tutustu julkaisuumme ja asiantuntijoidemme näkemyksiin: Recoding change

Marjukka Rantala

Marjukka on innovaattori ja liiketoimintamuotoilija, joka auttaa organisaatioita kasvattamaan innovaatiokyvykkyyttään ja vahvistamaan innovaatiokulttuuriaan. Hän yhdistää muotoiluajattelun ja liiketoimintaosaamisen asiakkaille räätälöityihin innovaatioprosesseihin. Yhteiskehittämällä ja kokeilemalla osallistetaan eri tahoja ja rakennetaan merkityksellisiä palveluita ja ekosysteemejä koko verkostolle, liiketoiminnalle ja lopulta yhteiskunnalle.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

During the past two years, I had the luxury to be part of a large-scale program that involved several development teams across the world. As an agile coach and scrum master in one of the teams, together with my colleagues, we built a development team that ended up being one of the best crews I’ve been working with so far. However, we didn’t get it right on the first – or even on the second try. There were some important lessons to be learned. In this post, I’ve listed my three most important takeaways.

Encourage active and respectful face-to-face communication

Ideally, all the teams should be co-located. There is no better way than to simply walk to another person and to start asking those questions. This overcomes any other means of communication. However, in a global environment, this is not always possible. Thus, it’s crucial that, if there are multiple teams in different locations, you really need to go out there and meet those people. Or, alternatively, fly them over to your country and make them feel comfortable. This is a must and we learned it the hard way. If you don’t have the travel budget, pick it from your own pocket – I can assure you it will be one of your best investments for the project.
After you have made acquaintances, use video conferencing tools as much as possible in everyday communication. It might feel awkward in the beginning, but again, it will improve how the teams communicate. If the other team does not have the equipment, it’s a great idea to buy them a proper webcam as a gift when you pay a visit.
Meeting people in person, having a laugh and working together, side-by-side makes all the difference. This will also enable people to establish common rules for working together more easily. Different cultures have different customs and e.g. ways of saying things. Like it or not, we also all have sub-conscious stereotypes of different countries and cultures. If the people you’re interacting with daily are mere virtual icons in your teleconferencing tool it easily becomes “us and them”. This is definitively not the setup to be in when you have to deal with more difficult issues.
So, in essence,

  • Co-locate the teams, or fly them over to visit as soon as you can
  • Get to know people, then use video conferencing tools and encourage relaxed communication
  • Beware of “us and them”

Enable the team to evolve and remember to have a safety net

Preferably, the team’s composition should not change too often. Effective communication within the team, building an identity and your sense of humour will take some time, so be patient. Yet, setting the team composition in stone from day one might be problematic. The skillset the team needs at the very beginning of the project is usually different from the skills team members require over a longer period of time. In the beginning, you may need to have more specialists working with, say, concepting and service design. Later on, as the product evolves, the team might gravitate more towards operations or security-related topics.
An experienced team can identify these needs themselves, but it’s worth making this clear from the very beginning: changing the composition of the team is natural as the project evolves and everyone should keep their eye on whether the team has the best fit to deliver at a given time. Of course, the team is usually very capable of learning new things and sharing skills, as long as there is a decent time frame for this. Sudden changes will affect the psychological safety of the team, so avoid hasty decisions – involve the team, they know best what is required.

An external coach can be valuable

The chemistry within the team is something to look after. Even the brightest minds don’t work well together if the way of working simply does not match each other. Active discussion and even strong opinions are quite all right, as long as the team can work things out. However, very strong personalities can sometimes dictate discussion, even unintentionally. In this case, there’s a great danger of losing valuable insights and ideas. To overcome this, the team can take advantage of a plethora of tools available ranging from online anonymous feedback systems to tools used in retrospectives. Also, having an external coach to facilitate these discussions can prove to be valuable. The team should be coached towards non-violent communication and you should lead the example. As a last resort, don’t be afraid to make changes to the team. Having a fruitful working environment weighs more in the longer run, even in the case where the team might temporarily lose some technical talent.
Lastly, the team should take care to produce an easy and fast onboarding process. You will never know when one of your team members finds the love of her life or even a better job opportunity – which is on the other side of the world. For a highly efficient team, it’s a great safety net to make sure that whenever new team members are joining, they will get going as quickly as possible. It will improve the ability of a team to get back in the normal pace and reduces the anxiety of a new member of the team starting anew. Make sure everyone knows how to get started, where to obtain credentials and access rights, where to look for introductory tutorials and so on. And when the new team member joins the team, her insights and perceptions of the project might prove very valuable – especially with regards to the on-boarding process, but also on the project in general. The team might be blind to things and habits that have lost their value a long time ago.
Three key points regarding team evolution:

  • Encourage people to step outside their comfort zone to learn new things – remember that changing the team composition should not be the first choice
  • However, the skills needed in the project might change over time – involve the team to determine what is required at a given moment and then proceed
  • Even the best teams will also face unexpected attrition, so be prepared

Be curious, challenge the status quo and empower the team

The same way as a newcomer to the team can see things differently, so the whole team can see the new project in a different light. There might be something very evident blocking the team on its way to success, which the team can immediately spot. So, challenging existing structures and the status quo should be encouraged.
When it comes to these blockers, there are many sayings, such as “it’s better to beg for forgiveness than to ask for permission”. With this kind of thinking it is often tempting to start from a clean slate. ”Things would be so much easier and more fun if we simply ditched this box here and recreated it ourselves”. Sound familiar? Honestly, if you don’t need it, get rid of it. Still, it’s good to think twice before blindly overhauling all the existing processes and tools already in place. They usually are there for a reason. Before making any big changes, the team needs to understand how the underlying system of work works.
The other point of view is that a fresh team does not yet carry the weight of the organization. Hopefully, the team is free of any strong opinions regarding other departments in the organization. As no bridges have yet burned, the team might be able to approach different parts of the organization in a more neutral way and thus learn more this way. This should be encouraged.
The point is to actively seek the actual users of the system, even if (and especially when) it has not been the custom, or when there is a proxy entity representing actual end-users. What are the users really trying to do – do they actually need this system? This is often overlooked, or users are misrepresented by some other entity. There might be existing tools or structures, parts of the system, that are then, once again, recreated. But the team can easily go on for a long time before really understanding what it is actually building and for whom – or does it even make sense? Once the team really understands the real needs, it should be empowered to make even bold decisions regarding what really should be done next.
In the end, it comes back to active communication. Perhaps it’s about pointing out the elephant in the room no-one else is willing to see. Then, having the right people expressing themselves in a polite but decisive manner – and at the same time being able to express and reason themselves clearly – will make a world of difference.
Remember that

  • A new team has ”fresh eyes” – try to benefit from it
  • There might be existing structures that, in the end, serve no real meaning
  • Understanding the system, i.e. what users are trying to achieve, is the key thing


From my experiences, I can guarantee that building a highly-effective team from scratch is challenging and will require some trial and error. If you work with a global customer and with different cultures and time zones, things will not get any easier.
There are many things to keep in mind, but always make sure that you communicate your intentions, what the team is currently doing and where you are heading next in the clearest and concise way possible.
Do your best to find the most suitable composition for the team. Try to keep changes to a minimum, but always remember to think ahead and have a plan B ready, if and when you are forced to change the team.
Encourage the team actively to seek a better way. Usually, things are in place for a reason and they can always be done differently. The trick is to know whether the features the team is implementing are actually taking the product forward from the real customer’s point of view or are they merely feats of engineering. And finally, always remember to ask why.

Kustaa Huhtala

Kustaa is a software professional with strong expertise in versatile modern technologies, agile methodologies and project management. He has also worked as a lead developer, agile coach and scrum master in several projects.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

This blog series is split into four parts:

  1. General information of secrets management
  2. Example how to store secrets into a version control
  3. Example how to use encrypted secrets in CI-pipelines
  4. Security issue and threat analysis based on previous examples

After the secrets are stored securely on a version control, it is time to look how a continuous integration pipeline should handle the secrets. In this guide, I’ll use Gitlab’s pipelines.

Configuring GCP

First of all, you have to create a new service account and a new KMS key which is used only by the service account.

  1. Head to, select the project used and create a service account
  2. Create the private key in JSON format and temporarily store it on your computer. It will be used later when configuring Gitlab CI-pipeline.
  3. Then open, select your preferred keyring (or create a new one) and create a new key
    1. Purpose: Symmetric encrypt/decrypt
    2. Rotation period: 7 days (I’ll tell about this on the last blog post)
  4. Select the key created and add the service account with decryption access (’Cloud KMS CryptoKey Decrypter’) to it

Modifying access to the cryptographic key

Encrypting with a new key

If you have already encrypted secrets, you must add the key to the secrets after setting up the new cryptographic key.

# Adding GCP key
sops -r -i --add-gcp-kms projects/<gcp project>/locations/global/keyRings/sops/cryptoKeys/gitlab-test api-key.json
# Removing GCP key
# sops -r -i --rm-gcp-kms projects/<gcp project>/locations/global/keyRings/sops/cryptoKeys/gitlab-test api-key.json
# -r option: 'generate a new data encryption key and reencrypt all values with the new key'

For .sops.yaml configuration, you have to add the new cryptographic key and re-encrypt the secrets. The previous blog post contained the Git pre-commit script which will re-encrypt all secrets if the configuration file is changed.

  # Global enc-files (typically for testing and dev-environment)
  - path_regex: .*\.enc(\.yaml|\.json)?$
    gcp_kms: projects/<gcp dev project>/locations/global/keyRings/sops/cryptoKeys/dev-sops-key,projects/<gcp dev project>/locations/global/keyRings/sops/cryptoKeys/gitlab-test

Gitlab configuration


You can add variables for the CI-pipeline in the project or group settings. I’ll add the following variables to the project settings (Gitlab > Project > Settings > CI/CD > Variables).

GCLOUD_PROJECT_NAME <project name>
GCLOUD_SERVICE_KEY <service account key file content in JSON-format)

CI Pipeline

Build contains following steps:

  1. Authenticate and setup gcloud CLI
  2. Install SOPS
  3. Decrypt secrets and cache them for the next build steps
    1. -script is the same that was used in the previous blog post.
decrypt secrets:
  image: google/cloud-sdk:alpine
    # Caches decrypted secrets to next build step (among with other untracked files)
    untracked: true
    # Authentication for google cloud
    - echo "$GCLOUD_SERVICE_KEY" > ${HOME}/gcloud-service-key.json
    - export GOOGLE_APPLICATION_CREDENTIALS=${HOME}/gcloud-service-key.json
    - gcloud auth activate-service-account --key-file ${HOME}/gcloud-service-key.json
    - gcloud config set project $GCLOUD_PROJECT_NAME
    # Install SOPS
    - apk update && apk add --no-cache ca-certificates
    - wget${SOPS_VERSION}/sops-${SOPS_VERSION}.linux -O /usr/local/bin/sops
    - chmod 0755 /usr/local/bin/sops
    # Install GNU findutils for proper regex support
    - apk add findutils
    - sh

Gitlab missing features and bugs

In the last part of blog series: what vulnerabilities my examples could contain and how to manage them.

Jarkko Koistinaho

Jarkko toimii Goforella teknisenä projektipäällikkönä ja hän on laatu- ja testausorientoitunut ohjelmistoalan ammattilainen. Testauksen lisäksi hän voi astua kehittäjän saappaisiin, Scrum Masteriksi tai tehdä järjestelmäasiantuntijalle tyypillisiä tehtäviä. Mallipohjainen testaus ja suorituskykytestaus ovat Jarkon erityisosaamisalueita.

Piditkö lukemastasi? Jaa se myös muille.

Passion for continuous improvement

It was already clear for me in high school, that I want to become an engineer. This was partly because I was not very keen on reading thick books for admission tests and partly because mathematics was easy for me and I believed, that technical education would provide many different career opportunities. However, I had no idea what those opportunities could be. Thus, I applied to the electrical engineering department at the University of Technology and was accepted.

The first course was about programming basics and I was immediately thrilled. I had never touched a computer before that.  It was amazing for me, that with the combination of my brain and the keypad I could accomplish all kinds of cool things on the computer screen. There were many boys hanging around in the computer class and offering their help, but I systematically rejected their offers and wanted to solve the programming exercises myself. This really paid off, because learning happens primarily by trial and error.

After graduation I wanted to move towards product development, because I felt, that it would give me the opportunity to do something unique that has not been done before. This was probably the most important decision during my entire career, although I did not realize it at the time. As a result of this choice, I have been involved in the development of forefront technologies and innovations throughout four decades:

  • 80’s: Embedded SW development for research vessel Geldysh and diving bell Mir, which were part of the Titanic movie, searching for the lost necklace
  • 90’s: Web services for the consumers, digital television and mobile games
  • 00’s: Smart phones
  • 10’s: Digitalization and Internet of Things

It is easy to understand, that this has required continuous learning and renewal to keep up with developments – not only technologies, but also business. Several paradigm shifts have taken place during this time.

Personally, I do not think that it has been very different being woman in tech compared to being a man. I have been very fortunate to have had managers and colleagues that have supported and trusted me. Understandably, there have been sometimes situations of gender related prejudice, but those have been due to stereotypical assumptions, which have been corrected quickly.  I have never felt ignored or diminished because of my gender.

Having said that, I do feel, that there is quite high pressure from the “environment” to squeeze us women into a certain kind of mold. For example, many people tend to think, that women are more suitable for non-technical or supporting roles than men even if they work in the IT industry. As a woman, you must be very determined to keep your targets and priorities clear to fight back against these kinds of forces.

I had both my children (boy and girl) at a fairly young age and combining work and family has always been part of my life. It has not always been easy, but for me, these two roles have strongly supported each other: an interesting job with all the challenges has been a necessary counter force to raising children and taking care of their well-being. Spending free time with family has given me a huge amount of energy and helped me to recover from the work. Children have taught me many useful skills, that can be applied also to work life.

Luckily, they are already teaching programming in elementary school now, so maybe I will have a chance to help my granddaughter with her programming exercises as I did with my daughter during her studies.

According to a colleague, my hidden superpower is an outstanding resistance to pressure. This skill is the result of 35 years of practice in priorization, determination and focus on the essential.

Psst, we are attending the Women in Tech Forum, so if you have any questions or just wanna have a chat, meet us there. More information: 

Read the previous parts of this blog series here:
A love for mathematics led the way
Subconscious career design
Value your skills – they are needed in tech
My career in tech – a continuous learning curve
Finding my own material to design
Working as a woman in tech

Terhi Vesanen

Terhi Vesanen työskentelee tällä hetkellä Goforella kasvujohtajana. Tässä roolissa hän vastaa toimintojen ja tietojärjestelmien kehittämisestä, tukien yrityksen kasvua ja samalla toteuttaen Goforen missiota tuottaa erinomaisia työntekijä- ja asiakaskokemuksia itseohjautuvassa organisaatiossa. Terhin tausta on tuotekehityksessä ja projektijohtamisessa, ja hänellä on intohimo jatkuvaan työskentelytapojen parantamiseen.

Piditkö lukemastasi? Jaa se myös muille.