A provocante leitura de “Ask Your Developer” traz o dilema de “Build or Die”, no qual empresas que não desenvolver seus softwares deixarão de existir.
A primeira reação pode soar extremo, mas considerando a relevância corporativa podemos afirmar que quem detém o desenvolvimento tem diferenciais competitivos relevantes. Nesse sentido, toda indústria será disruptada e dominada por um player de software, ficando com a maior parte do valor do mercado. Cabe então avaliar a relevância que quer ter e criar sua estratégia para o que irá construir!
“Every kind of company can become a software company—all you have to do is internalize the value of rapid iteration”
“But of course, to iterate, you first need to build. You can’t iterate on something you’ve bought off the shelf.”
“If you want to become a software builder, you need to start by changing the mindset of the entire organization.”
“Build vs. Die is becoming a natural law of business, just as evolution defines organic life on earth. This is simply survival of the fittest, where fitness is defined by how well companies can arrange magnetic particles”
A estratégia de construir envolve a cultura, a competência de inovação aberta e a visão de negócios.
Criar a cultura de engajar na observação de problemas e caminhos para solução de modo coletivo.
Desenvolver a competência de ser parte de um arranjo, de um grande LEGO, na qual você usa peças alheias para criar o seu objeto de valor.
Ter a liderança com visão de mercado para calibrar apostas de acordo com a realidade, contexto e aderência, do negócio.
As APIs já estão mudando o mundo
O autor do livro “Ask Your Developer” é fundador da Twilio e a leitura é gratificante também por conhecer mais sobre essa empresa. Afinal é uma gigante pouco conhecida. Seu modelo de negócios é fornecer API (as tais peças de LEGO) para que outras empresas criem seus objetos de valor. Só para entender e conhecer mais o case da Twilio, sua cultura centrada nos clientes e sua abordagem de liderança, vale a leitura!
No contexto que o mundo será dominado pelas melhores soluções em cada indústria, e as melhores soluções por sua vez trabalham em colaboração com outras soluções via API, ter a mentalidade do que desenvolver dentro de casa e o que adquirir dos outros é fundamental.
A defesa do autor é focar no desenvolvimento de tudo aquilo que for uma diferenciação real para seu cliente. Por exemplo, a solução da Uber para motoristas e passageiros precisa ser desenvolvida, mas nem tudo de modo proprietário, usar camadas e APIs de soluções de canal de atendimento não é um diferencial (e por isso usam Twilio).
Cabe aqui destacar uma vez mais a competência de inovação aberta: quais APIs existem? Quais parcerias posso fazer? Como posso co-criar com o ecossistema de inovação? Perguntas essenciais para a boa construção de seu arranjo diferencial.
“the key ingredient to unlocking innovation is cultural more than anything else, and that culture starts at the top”
“the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions.”
“when he asked me to solve a problem, I became more engaged.”
Uma cultura forte é aquela que engaja. O exemplo e coerência da liderança é que tornam o valor dessa cultura exponencial. O time é parte da solução, e o desenvolver não é apenas um tradutor de especificação em código, é um artista co-criando e propondo melhores caminhos.
Todos deveriam ser pessoas de software e saber liderar construções
A defesa do autor é clara quanto ao papel maior de ser uma pessoa de software. Não é algo apenas para quem programa, desenvolve ou faz design. É um papel para todos aqueles comprometidos em melhorar o mundo por meio de softwares.
Construir não é o real desafio. Construir bem, com real diferencial o é. Dai temos o passo de saber entender bem o problema e engajar as pessoas na construção da solução. A leitura desse livro é obrigatoria para todos que demandam times de desenvolvimento: como fazer isso é uma das grandes questões que o livro busca responder.
“When a developer is merely reading a specification document, they become isolated from the people who will use the software. The code becomes clunky and error prone because the developer didn’t know how people were going to use it.”
“The essence of autonomy is feeling trusted to make decisions.”
“I believe the goal isn’t better collaboration; it’s actually less collaboration.”
“This frees up teams to spend more time innovating, and less time in internal coordination meetings. The key is treating other parts of the company as customers rather than collaborators.”
Colaborar menos é ter menor necessidade de coordenação e maior foco no real chefe: os objetivos! Servir bem o cliente!
O nome do jogo é SERVIR SEUS CLIENTES
“The only way we can bring our corporate plans to life is by serving customers.”
O propósito de existir da empresa está em atender bem, melhorar a vida de seus clientes. Eis o papel da cultura de manter isso claro e evidente constantemente. Vencerá o jogo infinito aquelas empresas que optem pelo caminho de construir as soluções que entregam a melhor experiência do cliente!
Não deixe de ler “Ask Your Developer” para se inspirar e se preparar para esse jogo.
P.S: todas citações são do livro e não coloquei a página pois estou lendo no Kindle (logo tenho a posição apenas). Clique aqui caso queira comprar e começar sua leitura.