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.
Read the previous parts of this Women in tech 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
I’ve been working as a UX-designer at Gofore for two years now. My core skills are UI design, visual design, graphic design, prototyping and user studies. Service design is also close to my heart and luckily there is some overlap between the processes within UX design and service design.
One of the reasons that I work with technology is that it is closely related to my family. When I was little my father had a great career at Nokia. I think all three of us children were impressed with dad’s work: he made the technology industry look exciting and important. I don’t think any of us could tell what dad actually did for his job, but it sounded exciting anyway. Most importantly, I realised at a young age that the technology industry is the future. So, it’s not a surprise that I was already leaning towards the tech industry before I even realised it myself.
Both of my big brothers became interested in the tech industry at an early age and headed to the world of coding. However, I was attracted to visual design, different services and the desire to understand users’ needs. After high school I became an artisan and then went to Turku University of Applied Sciences to study design. The studies immediately felt right for me and I was excited about the program. However, finding the context was difficult because I did not consider myself in the world of traditional materials. Textiles, wood, metal and plastic all seemed strange to me. Traditional product design was far from what I wanted to do in the future. When I got familiar with service design, I felt relief that I was now moving in the right direction. Service design was not tied to a context or physical material. It was something bigger and more comprehensive.
When it came time to look for an internship, there were no other options for me than IT companies. I had a great desire to try a position in which I could pursue my own professional development. At the end of the application process I didn’t get an internship, but an actual job from Leadin, which Gofore later bought. It was truly a dream come true. My whole application process was long and at times really challenging and I really know how it tests your self-confidence. But if you have a clear goal and you are able to use feedback for self-reflection, you are very unlikely to fail.
Still today, almost my entire family is in the technology industry: my two brothers are Software Developers and my dad is a Project Manager. I enjoy my work every day because my projects vary a lot: from sector to sector, from one industry to another. My work is all about understanding the users’ needs and that is my passion.
In my opinion you can end up in tech-industry through many different ways. After all, my studies hardly emphasized this area, actually vice versa: traditional materials were still popular. I don’t think you need to know everything about the field in advance. Even though my mindset was towards tech-industry, I knew little about the industry itself. I just learned it through practice and dived deep into unknown. My best advice is just to be brave, curious and just do your best.
A failure I learned from: Long recruitment processes and many no-responses. Through failures and feedback, I got an idea of the direction in which I should develop myself. Honest and objective self-reflection was the most valuable skill that I learned from the recruitment processes.
Read the previous part of this Women in tech blog series here:
Working as a woman in tech
Humans are naive. If something is written in black on white, they believe it. When a contract states that the project fulfils certain requirements and will go online on a certain date, they believe it. In reality, it does not matter what the contract states. The project still probably fails.
Pig in a Poke
I’ve seen numerous occasions where software is sold based on an unrealistic contract. The contract includes all one could ever dream of. Fast schedule. Cheap price. And all the killer features listed in the requirements. The dream come true is hard to believe, so the contract contains also penalties. The penalties calm everyone down; a dream come true is possible, because otherwise someone is theoretically being punished.
If a deal looks too good to be true, it probably is.
– Michael Douglas (FBI Public Service Announcement)
In reality, the contract paper is just being used as a catalyst to get the project started. When the project hits the deadline, there are no other options that just keep going. The business owner wants results. The project is almost there. A few extra bucks and the project will be finished. You can’t really use the penalties, because they would just slow things down. In the worst case the subcontractor would end up bankrupt. That would definitely kill the velocity.
All this can be avoided by transparency. The transparent win-win attitude starts from the first steps of the negotiations. Win-win culture and honest transparency are tools to succeed in software projects. If the negotiations are run in an old-school mode, where the doubt is tangible, the project will fail.
Picture: You don’t want your project to hit a deadline
Software purchase follows a process: top management comes up with a new business vision, middle management creates a list of killer requirements and the procurement department sends RfQs to a few software companies they know. At the sales end: a sales person forwards the list of requirements to a project manager, who ends up with a work amount estimate. The sales person sets a price for the work and returns a quotation. Finally, the buyer chooses the cheapest quotation. Being a project manager, I see three different paths for the sales process.
1. Sell Cheap & Bargain for Extension
This is the classic tailboard (deadline) trick. It will leave everyone disappointed. This model starts with an offer the buyer can’t refuse.
I’m gonna make him an offer he can’t refuse.
– Marlon Brando (The Godfather)
When the project starts, everyone writes a lot of code using low maturity ways of working. Because the schedule is so challenging, the documentation, integration and testing is postponed until the main killer features are being launched. The project hits the deadline when it is 80% ready. Quite a few features are still under the development. All the money and time is spent. The system is “not quite yet” up and running.
Now starts the most strenuous cycle. Everyone searches for a scapegoat. Usually the project manager gets the blame. The next step is to bargain for extension; just a short and cheap extension, during which the last 20% of the work will be finalized. “It doesn’t make sense to flush all the expensive code we have already written!”. Yet another offer one cannot refuse.
The cycle of blaming and bargaining extension projects until the functionality reaches reasonable level or the project is courageously killed. The final price and schedule will be huge compared to the original offer.
Picture: Fixed price often results low quality high cost
2. Sell Buffer
Quality software houses seldom make cheap offers. Instead they make realistic offers. The requests usually contain only a partial set of requirements needed for a fully working system. Functional requirements are forgotten. Crucial user groups are totally missing from the requirements, because the top management has described only the new killer features. Nobody has thought about the non-functional requirements.
You can’t handle the truth!
– Jack Nicholson (A Few Good Men)
Therefore, a quality software house adds plenty of buffer into the fixed offer to cover all the unknowns. This sounds like a reasonable approach. However, nobody knows how this model would work, because the realistic offer never wins.
Picture: An honest man never wins
3. Sell Agile
Mobile, agile, hostile!
– Denzel Washington (Remember the Titans)
The agile mindset assumes that nobody understands requirements up front, so the project is split into short sprints. During the sprints developers work in tight co-operation with customer representatives. Each sprint ends with a working demo. Methods of high maturity are followed; everything is documented and tested. Mostly automated. The cost and output of each sprint are transparent for all the parties. The velocity is transparent for everyone. If a sprint doesn’t demonstrate the new features, velocity is 0. No excuses. The sprint is the heart rate of the project. The customer can stop the project at any moment. The customer can transfer the work to another subcontractor at any moment.
Picture: Agile is transparent
The advantages of an agile mindset can be exploited even while buying a fixed project. The offer can be divided into a prioritized list of must have, should have, could have features. The few first sprints will foretell the velocity, which helps to fine tune priorities. Transparent communication regarding priorities and velocity is crucial.
Everything Starts with The Procurement Process
The bidding process defines project success. The process determines whether the buyer buys the right things. The process must not bind such variables that will derail the project later. The process must consider variables vital for project success. Not a single person obtains all the needed knowledge for a successful purchase. Success always requires co-operation. Co-operation inside the target organization and co-operation with subcontractor candidates.
Aim of the text was to encourage the agile mindset. The best way to reach a successful software project is to spar the project objectives openly with subcontractor candidates. Transparent communication increases knowledge of all the parties regarding objectives, needs and implementation options. The fastest way to sink a project is to start with a shoddy purchase process. The easiest way to make a quality purchase is to use an external consultant to run the process. Someone who has a long track record of successful project purchases. The external consultant has the guts to challenge both buyer and seller. Both on mindset and content.
Finally, numerous saved software projects exist. Projects where the work has been bravely transferred to another contractor at the event of deadline. Transparent and fact based agile decision making is the corner stone of modern management.
Elämme palveluiden maailmassa. Tavaroiden omistaminen on työlästä ja vähän vanhanaikaistakin. En minäkään halua autoa sen vuoksi, että voisin omistaa sen. Tarvitsen autoa siihen, että voin helposti liikkua paikasta toiseen. En siihen, että voin korjata ja huoltaa sitä, vaihtaa renkaita, käydä autopesussa, jne. Jos asuisin Helsingissä, voisin liittyä autojen yhteiskäyttöpalveluun ja maksaa auton käytöstä vain siltä ajalta, kun sitä todella käytän. Näppärää. Ja ekologistakin.
Digitalisaatio tarjoaa mahdollisuudet ihan uudenlaiseen toimintaan: jättikokoinen majoituspalveluyritys Airbnb ei omista ensimmäistäkään kiinteistöä eikä maailman laajimmalla taksiyrityksellä Uberilla ole yhtään autoa. Maailma on muuttunut pysyvästi. Tämän muutoksen myötä on tullut tarve osaamiseen, jonka avulla voidaan tuottaa uusia ja innovatiivisia palveluita. Muotoilijat ovat kautta aikojen pyrkineet luomaan esineitä, jotka helpottavat arkea – nyt on tarve laajentaa tätä osaamista kokonaispalveluiden muotoiluun. Moniin yrityksiin onkin perustettu palvelumuotoiluyksikkö ja palkattu palvelumuotoilijoita. Mutta palvelumuotoilijoita – onko heitä?
Hyvä palvelu vastaa asiakkaan tarpeeseen ja tuottaa taloudellista hyötyä palvelun tarjoajalle. Jotta palvelu on toteutuessaan kaikinpuolin toimiva ja pystyy hyödyntämään uutta teknologiaa, tarvitaan vahvaa arkkitehtuuriosaamista ja tietoteknistä ratkaisukyvykkyyttä. Lisäksi tarvitaan graafikko luomaan houkutteleva ulkoasu ja käyttäjätyön asiantuntija varmistamaan loppukäyttäjien huomioiminen. Sekä paljon muuta erikoisosaamista. Hyvän, helpon ja houkuttelevan palvelun innovointiin, suunnitteluun ja toteuttamiseen tarvitaan monenlaista osaamista, avointa mieltä ja kiimaista innokkuutta palvelun aikaansaamiseksi. Siihen ei yksi ihminen pysty. Eikä kaksi. Ei edes palvelumuotoilija. Siihen tarvitaan joukko hyvällä mielikuvituksella varustettuja ammattilaisia, innovointia tukeva yrityskulttuuri ja aito halu ymmärtää asiakkaan tarpeita.
Palvelumuotoilussa asiakas, tuotettavan palvelun käyttäjä, on keskiössä. Ei vain palvelun suunnitteluvaiheessa vaan koko toteuttamisprosessin ajan. Jotta palvelu toteuttaisi asiakkaan tarpeen, on eri osa-alueiden ammattilaisten ja asiakkaan pystyttävä luomaan yhdessä visio uudesta palvelusta. Jokainen tulee prosessiin mukaan omista – hyvinkin erilaisista – lähtökohdista. Tämän vuoksi tarvitaan ideoita konkretisoivia ja innovaatiota ruokkivia menetelmiä, joista monet ovat lähtöisin perinteisen muotoilun toimintatavoista.
Digitalisoituvassa maailmassa selviävät ne, jotka ovat valppaina ja oivaltavat uudet mahdollisuudet. Tarvitaan myös rohkeutta kokeilla ja uskallusta muuttua. Menestyksen ratkaisee se, millaiseksi yritys palvelunsa muotoilee. Siihen tarvitaan eri osa-alueiden rohkeita osaajia, joista jokaisessa asuu pieni palvelumuotoilija.